Network Working Group T. Lemon
Request for Comments: 3396 Nominum, Inc.
Updates: 2131 S. Cheshire
Category: Standards Track Apple Computer, Inc.
November 2002
Encoding Long Options
in the Dynamic Host Configuration Protocol (DHCPv4)
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document specifies the processing rules for Dynamic Host Configuration Protocol (DHCPv4) options that appear multiple times in the same message. Multiple instances of the same option are generated when an option exceeds 255 octets in size (the maximum size of a single option) or when an option needs to be split apart in order to take advantage of DHCP option overloading. When multiple instances of the same option appear in the options, file and/or sname fields in a DHCP packet, the contents of these options are concatenated together to form a single option prior to processing.
この文書では、同じメッセージ内に複数回表示される動的ホスト構成プロトコル（DHCPv4の）オプションのための処理規則を指定します。同じオプションの複数のインスタンスは、オプションのサイズが255個のオクテットを超える場合（1つのオプションの最大サイズ）を生成またはオプションは、DHCPオプションのオーバーロードを利用するために間隔を分割する必要がある場合にされています。同じオプションの複数のインスタンスは、DHCPパケットのオプション、ファイルおよび/またはsnameのフィールドに表示された場合、これらのオプションの内容は、処理の前に1つのオプションを形成するために一緒に連結されています。
This document updates RFC 2131 [3] by clarifying the rules for option concatenation specified in section 4.1. It is expected that the reader will be familiar with this portion of RFC 2131. The text in section 4.1 that reads "Options may appear only once, unless otherwise specified in the options document." should be considered as deleted.
セクション4.1で指定されたオプションを連結するためのルールを明確にすることで、この文書の更新RFC 2131 [3]。読者はRFC 2131のこの部分読み込むセクション4.1のテキストに精通しているであろうことが期待されている「それ以外のオプション文書に指定がない限りオプションは、一度だけ表示されることがあります。」削除されたと考えるべきです。
The DHCP protocol [3] specifies objects called "options" that are encoded in the DHCPv4 packet to pass information between DHCP protocol agents. These options are encoded as a one-byte type code, a one-byte length, and a buffer consisting of the number of bytes specified in the length, from zero to 255.
DHCPプロトコル[3]はDHCPプロトコルエージェント間で情報を渡すためのDHCPv4パケットに符号化される「オプション」と呼ばれるオブジェクトを指定します。これらのオプションは、1バイトのタイプコード、1バイトの長さ、およびゼロから255まで、長さが指定されたバイト数からなるバッファとして符号化されます。
However, in some cases it may be useful to send options that are longer than 255 bytes. RFC 2131 [3] specifies that when more than one option with a given type code appears in the DHCP packet, all such options should be concatenated together. It does not, however, specify the order in which this concatenation should occur.
しかし、いくつかのケースでは、255バイトより長いオプションを送信するために有用である可能性があります。 RFC 2131 [3]は、指定された型コードを使用して複数のオプションは、DHCPパケットに表示されたときに、そのようなすべてのオプションを一緒に連結することを指定します。それは、しかし、この連結が行われるべき順序を指定していません。
We specify here the ordering that MUST be used by DHCP protocol agents when sending options with more than 255 bytes. This method also MUST be used for splitting options that are shorter than 255 bytes, if for some reason the encoding agent needs to do so. DHCP protocol agents MUST use this method whenever they receive a DHCP packet containing more than one occurrence of a certain type of option.
ここでは255を超えるバイトのオプションを送信するときにDHCPプロトコルエージェントによって使用されなければならない順序を指定します。符号化エージェントがそうする必要が何らかの理由であれば、この方法はまた、255バイトより短い分割オプションを使用しなければなりません。それらはオプションの特定のタイプの複数の発生を含むDHCPパケットを受信するたびに、DHCPプロトコルエージェントは、この方法を使用しなければなりません。
DHCP Throughout this document, the acronym "DHCP" is used to refer to the Dynamic Host Configuration Protocol as specified in RFC 2131 [3] and RFC 2132 [4].
RFC 2131で指定され、この文書、頭文字「DHCP」を通じて、DHCPは、動的ホスト構成プロトコルを参照するために使用されている[3]およびRFC 2132 [4]。
DHCPv4 We have used the term "DHCPv4" in the abstract for this document to distinguish between the DHCP protocol for IPv4 as defined in RFC 2131 and RFC 2132 and the DHCP protocol for IPv6, which, at the time that this document was written, was still under development.
RFC 2131およびRFC 2132で定義されたこの文書はIPv4のDHCPプロトコルを区別するために私たちは、抽象的に用語「DHCPv4の」を使用していたDHCPv4と、この文書が書かれた時点で、だった、IPv6の、のためのDHCPプロトコルまだ開発中。
DHCP protocol agents This refers to any device on the network that sends or receives DHCP packets - any DHCP client, server or relay agent. The nature of these devices is not important to this specification.
DHCPプロトコルエージェントこれは、DHCPパケットを送受信する、ネットワーク上の任意のデバイスを指し、 - 任意のDHCPクライアント、サーバーまたはリレーエージェント。これらのデバイスの性質は、この仕様書には重要ではありません。
Encoding agent The DHCP protocol agent that is composing a DHCP packet to send.
送信するDHCPパケットを構成されたDHCPプロトコルエージェントは、エージェントをコードします。
Decoding agent The DHCP protocol agent that is processing a DHCP packet it has received.
デコーディングは受信したDHCPパケットを処理しているエージェントのDHCPプロトコルエージェント。
Options DHCP options are collections of data with type codes that indicate how the options should be used. Options can specify information that is required for the DHCP protocol, IP stack configuration parameters for the client, information allowing the client to rendezvous with DHCP servers, and so on.
オプションのDHCPオプションはオプションを使用すべきかを示すタイプコードとデータの集まりです。オプションは、その上の情報は、クライアントがDHCPサーバとランデブーすることができ、DHCPプロトコルのために必要な情報、クライアントのIPスタック構成パラメータを指定し、することができます。
Option overload The DHCP packet format is based on the BOOTP packet format defined in RFC 951 [1]. When used by DHCP protocol agents, BOOTP packets have three fields that can contain options. These are the optional parameters field, the sname field, and the filename field. The DHCP options specification [4] defines the DHCP Overload option, which specifies which of these three fields is actually being used in any given DHCP message to store DHCP options.
オプションは、DHCPパケットのフォーマットは、RFC 951で定義されたBOOTPパケットフォーマットに基づいて過負荷[1]。 DHCPプロトコルエージェントによって使用される場合は、BOOTPパケットはオプションを含めることができる3つのフィールドを持っています。これらは、オプションのパラメータのフィールド、snameフィールド、およびファイル名のフィールドです。 DHCPオプション仕様[4]実際にDHCPオプションを格納するために任意のDHCPメッセージで使用されているこれら3つのフィールドかを指定DHCPオーバーロード・オプションを定義します。
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in BCP 14, RFC 2119 [2].
この文書に記載されている、キーワード "MAY"、「MUST、 "MUST NOT"、 "任意"、 "推奨"、 "SHOULD"、および "the" はならない、BCP 14、RFC 2119に記載したように解釈されるべきです2]。
This specification applies when a DHCP agent is encoding a packet containing options, where some of those options must be broken into parts. This need can occur for two reasons. First, it can occur because the value of an option that needs to be sent is longer than 255 bytes. In this case, the encoding agent MUST follow the algorithm specified here. It can also occur because there is not sufficient space in the current output buffer to store the option, but there is space for part of the option, and there is space in another output buffer for the rest. In this case, the encoding agent MUST either use this algorithm or not send the option at all.
DHCPエージェントは、これらのオプションの一部が部分に分割する必要があるオプションを含むパケットを符号化されたときにこの仕様は適用されます。この必要性は、2つの理由で発生する可能性があります。送信する必要があるオプションの値が255バイトよりも長いのでまず、それが発生する可能性があります。この場合は、符号化エージェントは、ここで指定されたアルゴリズムに従わなければなりません。オプションを保存するための電流出力バッファに十分なスペースがないためにも発生しますが、オプションの一部のためのスペースがあり、スペースが残りのための別の出力バッファにあります。この場合は、符号化エージェントは、このいずれかのアルゴリズムを使用するか、まったくオプションを送ってはいけません。
This specification also applies in any case where a DHCP protocol agent has received a DHCP packet that contains more than one instance of an option of a given type. In this case, the agent MUST concatenate these separate instances of the same option in the way that we specify here.
本明細書はまた、DHCPプロトコルエージェントが所与のタイプのオプションの複数のインスタンスを含むDHCPパケットを受信したいずれの場合にも当てはまります。この場合、エージェントは、我々がここで指定した方法で、同じオプションのこれらの別々のインスタンスを連結しなければなりません。
This option updates the Dynamic Host Configuration Protocol [3] and DHCP Options and BOOTP vendor extensions [4] documents. However, because many currently-deployed DHCP protocol agents do not implement option concatenation, DHCP protocol agents should be careful not to transmit split options unless either it will not matter if the recipient cannot correctly reassemble the options, or it is certain that the recipient implements concatenation.
このオプションは、[4]文書[3]とDHCPオプションおよびBOOTPベンダー拡張動的ホスト構成プロトコルを更新します。多くの現在デプロイDHCPプロトコルエージェントは、オプションの連結を実装していないので、しかし、DHCPプロトコルエージェントは、スプリットオプションを送信しないように注意する必要があり、受信者が正しくオプションを再構築することができない場合、それは問題ではないでしょうか、受信者が実装していることは確かであるいずれかの場合を除き連結。
Let us divide all DHCP options into two categories - those that, by definition, require implementation of the mechanisms defined in this document, and those that do not. We will refer to the former as concatenation-requiring options, and the latter as non-concatenation-requiring options. In order for an option to be a concatenation-requiring option, the protocol specification that defines that option must require implementation of option splitting and option concatenation as described in this document, by specifically referencing this document.
、定義によって、この文書で定義されたメカニズムの実装を必要とするもの、とそうでないもの - 私たちは二つのカテゴリーにすべてのDHCPオプションを分割してみましょう。者らは、非連結要求性オプションとして連結要求性オプションとして、前者と後者に言及します。この文書に記載されているように、連結要求性選択すべきオプションのために、そのオプションを規定するプロトコル仕様は、具体的には、この文書を参照することにより、オプション分割及びオプション連結の実装を必要としなければなりません。
A DHCP protocol agent SHOULD NOT split an option as described in this document unless it has no choice, or it knows that its peer can properly handle split options. A peer is assumed to properly handle split options if it has provided or requested at least one concatenation-requiring option. Alternatively, the administrator of the agent generating the option can specifically configure the agent to assume that the recipient can correctly concatenate options split as described in this document.
それは選択の余地を持っていない、またはそれは、そのピアが適切に分割オプションを扱うことができることを知っている場合を除き、この文書で説明するようにDHCPプロトコルエージェントは、オプションを分割すべきではありません。ピアは、それが提供されるか、または少なくとも一つの連結要求性オプションを要求した場合に適切に分割オプションを処理するために想定されます。また、オプションを生成するエージェントの管理者は、特に、受信者が正しく、この文書に記載されたオプションは、分割連結することができていることを前提としてエージェントを設定することができます。
Some implementors may find it easiest to only split concatenation-requiring options, and never split non-concatenation-requiring options. This is permissible. However, an implementation which supports any concatenation-requiring option MUST be capable of concatenating received options for both concatenation-requiring and non-concatenation-requiring options.
いくつかの実装はそれを唯一の分割連結-必要なオプションを最も簡単に見つけること、そして決してスプリット非連結、必要なオプションがあります。これは許容されます。しかし、任意の連結要求性オプションをサポートする実装は、連結要求性及び非連結要求性オプションの両方のために受け取ったオプションを連結することができなければなりません。
No restrictions apply to option concatenation when a DHCP agent receives a DHCP message. Any DHCP protocol agent that implements the mechanisms described in this document can assume that when it receives two options of the same type, it should concatenate them.
DHCPエージェントはDHCPメッセージを受信したときには制限はオプションの連結に適用されません。この文書で説明するメカニズムを実装するすべてのDHCPプロトコルエージェントは、同じタイプの2つのオプションを受信したとき、それはそれらを連結すべきであると仮定することができます。
DHCP options can be stored in the DHCP packet in three separate portions of the packet. These are the optional parameters field, the sname field, and the file field, as described in RFC 2131 [3]. This complicates the description of the option splitting mechanism because there are three separate fields into which split options may be placed.
DHCPオプションは、パケットの3つの別々の部分にDHCPパケットに格納することができます。これらはRFC 2131に記載されているように、オプションのパラメータフィールド、snameフィールド、およびファイル・フィールドである[3]。オプションが配置されてもよい分割その中に3つの別々フィールドがあるので、これはオプション分割機構の説明を複雑にします。
To further complicate matters, an option that doesn't fit into one field can't overlap the boundary into another field - the encoding agent must instead break the option into two parts and store one part in each buffer.
さらに問題を複雑にし、一つのフィールドに収まらないオプションは、別のフィールドに境界線をオーバーラップすることはできません - 符号化エージェントは代わりに二つの部分にオプションを破ると、各バッファ内の一部を格納しなければなりません。
To simplify this discussion, we will talk about an aggregate option buffer, which will be the aggregate of the three buffers. This is a logical aggregation - the buffers MUST appear in the locations in the DHCP packet described in RFC 2131 [3].
ここでの説明を簡単にするために、我々は3つのバッファの集計となります集合オプションバッファ、についてお話します。これは論理的な集合である - バッファはRFC 2131に記載されたDHCPパケット内の場所に現れなければならない[3]。
The aggregate option buffer is made up of the optional parameters field, the file field, and the sname field, in that order.
集合オプションバッファは、そのためには、オプションのパラメータフィールド、ファイルのフィールド、およびsnameフィールドで構成されています。
WARNING: This is not the physical ordering of these fields in the DHCP packet.
警告：これはDHCPパケット内のこれらのフィールドの物理的な順序ではありません。
Options MUST NOT be stored in the aggregate option buffer in such a way that they cross either boundary between the three fields in the aggregate buffer.
オプションは、彼らが集約バッファ内のいずれか3つのフィールド間の境界をまたぐように集合オプションバッファに格納されてはなりません。
The encoding agent is free to choose to use either or both the sname field and file field. If the encoding agent does not choose to use either or both of these two fields, then they MUST NOT be considered part of the aggregate option buffer in that case.
符号化エージェントは、どちらかまたはsnameフィールドとファイルフィールドの両方を使用することを選択して自由です。符号化エージェントは、これらの二つのフィールドのいずれかまたは両方を使用することを選択しない場合、それらはそのときの集合オプションバッファの一部とみなされてはなりません。
Encoding agents decide to split options based on the reasons we have described in the preceding section entitled "applicability".
エンコーディングエージェントは、我々が「適用」と題し、前のセクションで説明してきた理由のに基づいてオプションを分割することを決定しました。
Options can be split on any octet boundary. No split portion of an option that has been split can contain more than 255 octets. The split portions of the option MUST be stored in the aggregate option buffer in sequential order - the first split portion MUST be stored first in the aggregate option buffer, then the second portion, and so on. The encoding agent MUST NOT attempt to specify any semantic information based on how the option is split.
オプションは、任意のオクテット境界で分割することができます。分割されているオプションのスプリット部分は、255個のを超えるオクテットを含めることはできません。オプションの分割部分が順番に集合オプションバッファに格納しなければならない - 第1分割部分は、そうで第2部分、集合オプションバッファに最初に格納しなければならず。符号化エージェントはオプションが分割されている方法に基づいて任意の意味情報を指定するのを試みてはいけません。
Note that because the aggregate option buffer does not represent the physical ordering of the DHCP packet, if an option were split into three parts and each part went into one of the possible option fields, the first part would go into the optional parameters field, the second part would go into the file field, and the third part would go into the sname field. This maintains consistency with section 4.1 of RFC 2131 [3].
オプションは三つの部分に分割し、各部分が可能なオプションフィールドの1に入った場合は集合オプションバッファは、DHCPパケットの物理的な順序を表すものではないのでことに注意してください、最初の部分は、オプションのパラメータフィールドに行くだろう、第二部では、ファイルのフィールドに行くだろう、と3番目の部分はsnameフィールドに行くだろう。これは、RFC 2131のセクション4.1 [3]との整合性を維持します。
Each split portion of an option MUST be stored in the aggregate option buffer as if it were a normal variable-length option as described in RFC 2132 [4]. The length fields of each split portion of the option MUST add up to the total length of the option data. For any given option being split, the option code field in each split portion MUST be the same.
RFC 2132に記載されているように、それは通常の可変長オプションであるかのようにオプションの各分割部分[4]は集合オプションバッファに格納しなければなりません。オプションの各分割部の長さフィールドは、オプションデータの全体の長さにならなければなりません。任意のオプションが分割されるため、各分割部分のオプションコードフィールドは同じでなければなりません。
When a decoding agent is scanning an incoming DHCP packet's option buffer and finds two or more options with the same option code, it MUST consider them to be split portions of an option as described in the preceding section.
復号化エージェントは、着信DHCPパケットのオプション・バッファをスキャンし、同じオプションコードを有する2つの以上のオプションを発見したとき、それは、前のセクションで説明したようにオプションの部分を分割するためにそれらを考慮しなければなりません。
In the case that a decoding agent finds a split option, it MUST treat the contents of that option as a single option, and the contents MUST be reassembled in the order that was described above under encoding agent behavior.
復号化エージェントがスプリットオプションを見つけた場合には、1つのオプションとして、そのオプションの内容を扱わなければなりません、その内容は、符号化エージェントの動作の下で説明した順序で再構築されなければなりません。
The decoding agent should ensure that when the option's value is used, any alignment issues that are particular to the machine architecture on which the decoding agent is running are accounted for - there is no requirement that the encoding agent align the options in any particular way.
復号化エージェントは、オプションの値を使用した場合、復号化エージェントが実行されているマシンのアーキテクチャに特有の任意のアラインメントの問題が考慮されていることを確認すべきである - 符号化剤は、任意の特定の方法でオプションを揃える必要はありません。
There is no semantic meaning to where an option is split - the encoding agent is free to split the option at any point, and the decoding agent MUST reassemble the split option parts into a single object, and MUST NOT treat each split portion of the option as a separate object.
符号化エージェントは、任意の時点でオプションを分割して自由である、復号エージェントは1つのオブジェクトに分割オプションパーツを再構築しなければならない、とオプションの各分割部分を処理てはならない - オプションは、分割された場所への意味論的な意味はありません別個のオブジェクトとして。
Consider an option, Bootfile name (option code 67), with a value of "/diskless/foo". Normally, this would be encoded as a single option, as follows:
「/ディスクレス/ foo」というの値で、オプション、ブートファイル名（オプションコード67）を考えてみましょう。次のように通常、これは、1つのオプションとしてエンコードされます。
+----+----+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 67 | 13 | / | d | i | s | k | l | e | s | s | / | f | o | o |
+----+----+---+---+---+---+---+---+---+---+---+---+---+---+---+
If an encoding agent needed to split the option in order to fit it into the option buffer, it could encode it as two separate options, as follows, and store it in the aggregate option buffer in the following sequence:
符号化エージェントはオプションバッファにそれを合わせるためにオプションを分割する必要がある場合、それは次のように2つの別々のオプションとして、それをエンコードして、次の順序で集合オプションバッファに格納することができます：
+----+---+---+---+---+---+---+---+---+
| 67 | 7 | / | d | i | s | k | l | e |
+----+---+---+---+---+---+---+---+---+
+----+---+---+---+---+---+---+---+
| 67 | 6 | s | s | / | f | o | o |
+----+---+---+---+---+---+---+---+
This document raises no new security issues. Potential exposures to attack in the DHCP protocol are discussed in section 7 of the DHCP protocol specification [3] and in Authentication for DHCP Messages [5].
この文書は、どんな新しい安全保障問題も提起しません。 DHCPメッセージの[3]と認証でDHCPプロトコルの攻撃に対する潜在的エクスポージャーDHCPプロトコル仕様のセクション7に記載されている[5]。
Note that the authentication option itself can be split; in such cases implementations must be careful when setting the authentication field to zero (prior to generation or verification of the MAC) as it may be split across multiple options.
認証オプション自体を分割することができることに注意してください。それは複数のオプションに分割することができるように（前MACの生成や検証に）ゼロに認証フィールドを設定するとき、このような場合には実装は注意しなければなりません。
[1] Croft, W. and J. Gilmore, "BOOTSTRAP PROTOCOL (BOOTP)", RFC 951, September 1985.
[1]クロフト、W.及びJ.ギルモア、 "ブートストラッププロトコル（BOOTP）"、RFC 951、1985年9月。
[2] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーの、S.、 "要件レベルを示すRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月を。
[3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[3] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[4] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[4]アレクサンダー、S.とDroms、R.、 "DHCPオプションとBOOTPベンダー拡張機能"、RFC 2132、1997年3月。
[5] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[5] Droms、R.とW. Arbaugh、 "DHCPメッセージの認証"、RFC 3118、2001年6月。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
Ted Lemon Nominum, Inc. 2385 Bay Road Redwood City, CA 94043 USA
テッド・レモンノミナム社2385ベイロードレッドウッドシティー、CA 94043 USA
EMail: mellon@nominum.com
メールアドレス：mellon@nominum.com
Stuart Cheshire Apple Computer, Inc. 1 Infinite Loop Cupertino California 95014 USA
スチュアートチェシャーたApple Computer、Inc. 1無限ループクパチーノ、カリフォルニア95014 USA
Phone: +1 408 974 3207 EMail: rfc@stuartcheshire.org
電話：+1 408 974 3207 Eメール：rfc@stuartcheshire.org
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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 assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
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機能のための基金は現在、インターネット協会によって提供されます。