RFC3396 日本語訳
3396 Encoding Long Options in the Dynamic Host Configuration Protocol(DHCPv4). T. Lemon, S. Cheshire. November 2002. (Format: TXT=18779 bytes) (Updates RFC2131) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Lemon
Request for Comments: 3396 Nominum, Inc.
Updates: 2131 S. Cheshire
Category: Standards Track Apple Computer, Inc.
November 2002
コメントを求めるワーキンググループT.レモン要求をネットワークでつないでください: 3396のNominum Inc.アップデート: 2131秒間チェーシャー州カテゴリ: 標準化過程アップル・コンピューターInc.2002年11月
Encoding Long Options
in the Dynamic Host Configuration Protocol (DHCPv4)
Dynamic Host Configuration Protocolにおける長いオプションをコード化します。(DHCPv4)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
このドキュメントは同じメッセージに複数の回現れるDynamic Host Configuration Protocol(DHCPv4)オプションのための処理規則を指定します。 オプションがサイズ(ただ一つのオプションの最大サイズ)における255の八重奏を超えているか、またはオプションが、DHCPオプション積みすぎを利用するために分けられる必要があるとき、同じオプションの複数のインスタンスが発生しています。 同じオプションの複数のインスタンスがDHCPパケットにオプション、ファイル、そして/または、sname分野に現れると、これらのオプションの内容は、処理の前にただ一つのオプションを形成するために一緒に連結されます。
1. Introduction
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で指定されたオプション連結のための規則をはっきりさせることによって、RFC2131[3]をアップデートします。 読者がRFC2131のこの一部になじみ深くなると予想されます。 テキストは中でそれが「オプションが一度だけ現れるかもしれません、別の方法でオプションドキュメントで指定されない場合」読み込む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まで。
Lemon & Cheshire Standards Track [Page 1] RFC 3396 Encoding Long Options in DHCPv4 November 2002
DHCPv4 November 2002の長いオプションをコード化するレモンとチェーシャー州標準化過程[1ページ]RFC3396
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バイトより長いオプションを送るのは役に立つかもしれません。 RFC2131[3]は、与えられたタイプコードによる1つ以上のオプションが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バイトより短い分かれるオプションにこのメソッドも使用しなければなりません、ある理由でコード化しているエージェントが、そうする必要があるなら。 彼らが、あるタイプのオプションの1回以上の発生を含むDHCPパケットを受けるときはいつも、DHCPプロトコルエージェントはこのメソッドを使用しなければなりません。
2. Terminology
2. 用語
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].
このドキュメント、DHCP Throughout頭文字語"DHCP"は、RFC2131[3]とRFC2132[4]で指定されているとDynamic Host Configuration Protocolを呼ぶのに使用されます。
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.
DHCPv4 Weは「このドキュメントがIPv4のためにRFC2131とRFC2132で定義されるようにDHCPプロトコルを見分ける要約のDHCPv4"とIPv6のためのDHCPプロトコル」という用語を使用しました。IPv6はこのドキュメントが書かれた時にまだ開発中でした。
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プロトコルエージェントThisは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プロトコルに必要である情報、クライアントへのIPスタック設定パラメータ、クライアントがDHCPサーバで集合できる情報などを指定できます。
Lemon & Cheshire Standards Track [Page 2] RFC 3396 Encoding Long Options in DHCPv4 November 2002
DHCPv4 November 2002の長いオプションをコード化するレモンとチェーシャー州標準化過程[2ページ]RFC3396
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パケットがフォーマットするオプションオーバーロードはRFC951[1]で定義されたBOOTPパケット・フォーマットに基づいています。 DHCPプロトコルエージェントによって使用されると、BOOTPパケットには、オプションを含むことができる3つの分野があります。 これらは、任意のパラメタ分野と、sname分野と、ファイル名分野です。 DHCPオプション仕様[4]はDHCP Overloadオプションを定義して、どれがこれらの3つの分野についてどれを指定するかは実際にDHCPオプションを保存するどんな与えられたDHCPメッセージでも使用されています。
3. Requirements Language
3. 要件言語
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].
そして、このドキュメント、「5月」というキーワードで「必須、「必須NOT」、「任意」の、そして、「お勧め」の“SHOULD"、「」、BCP14で説明されるように解釈されることになっていてください、RFC2119[2]、」であるべきです
4. Applicability
4. 適用性
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プロトコルエージェントが与えられたタイプのオプションの1つ以上のインスタンスを含む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.
このオプションはDynamic Host Configuration Protocol[3]、DHCP Options、およびBOOTPベンダー拡大[4]ドキュメントをアップデートします。 しかしながら、多くの現在配布している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
すべてのDHCPオプションを2つのカテゴリに分割しましょう--定義上本書では定義されたメカニズムの実装を必要とするもの、およびそうしないそれら。 私たちは、オプションと連結が必要な前者を呼んで、オプションとして連結が非必要な後者を呼ぶつもりです。 オプションがaである命令で
Lemon & Cheshire Standards Track [Page 3] RFC 3396 Encoding Long Options in DHCPv4 November 2002
DHCPv4 November 2002の長いオプションをコード化するレモンとチェーシャー州標準化過程[3ページ]RFC3396
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.
連結必要さオプション、そのオプションを定義するプロトコル仕様は本書では説明されるようにオプションの分かれるのとオプション連結の実装を必要としなければなりません、明確にこのドキュメントに参照をつけることによって。
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プロトコルエージェントSHOULD NOTが本書では選択の余地がある場合説明されるようにオプションを分けたか、またはそれは、同輩が適切に分裂オプションを扱うことができるのを知っています。 少なくとも1つのオプションを連結が必要な提供するか、または要求したなら、同輩が適切に分裂オプションを扱うと思われます。 あるいはまた、オプションを生成するエージェントの管理者は、受取人が正しく本書では説明されるように分けられたオプションを連結できると仮定するために明確にエージェントを構成できます。
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つのオプションを受け取るとき、それらを連結するべきであると仮定できます。
5. The Aggregate Option Buffer
5. 集合オプションバッファ
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.
パケットの3つの別々の部分のDHCPパケットにDHCPオプションを保存できます。 これらは、RFC2131[3]で説明されるように任意のパラメタ分野と、sname分野と、ファイル分野です。 分裂オプションが置かれるかもしれない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.
さらに件を複雑にするために、1つの分野に収まらないオプションは別の分野に境界を重ね合わせることができません--コード化しているエージェントは、代わりに2つの部品にオプションを始めて、各バッファに一部を保存しなければなりません。
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つのバッファの集合になるでしょう)。 これは論理的な集合です--バッファはRFC2131[3]で説明されたDHCPパケットの位置に現れなければなりません。
The aggregate option buffer is made up of the optional parameters field, the file field, and the sname field, in that order.
集合オプションバッファは任意のパラメタ分野、ファイル分野、およびsname分野で作られます、そのオーダーで。
Lemon & Cheshire Standards Track [Page 4] RFC 3396 Encoding Long Options in DHCPv4 November 2002
DHCPv4 November 2002の長いオプションをコード化するレモンとチェーシャー州標準化過程[4ページ]RFC3396
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分野とファイルがさばくどちらかか両方を使用するのを自由に選ぶことができます。 コード化しているエージェントが、これらの2つの分野のどちらかか両方を使用するのを選ばないなら、それらはその場合集合オプションバッファの考えられた部分であるはずがありません。
6. Encoding Agent Behavior
6. エージェントの振舞いをコード化します。
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以上の八重奏を含むことができません。 連続したオーダーにおける集合オプションバッファにオプションの分裂部分を保存しなければなりません--最初に、集合オプションバッファ(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].
オプションが3つの部品に分けられて、各部分が可能なオプション・フィールドの1つに入るなら、集合オプションバッファがDHCPパケットの物理的な注文を表さないので最初の部分が任意のパラメタ野原に入って、第二部がファイル野原に入って、3番目の部分がsname野原に入ることに注意してください。 これはRFC2131[3]のセクション4.1がある一貫性を維持します。
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.
まるでそれがRFC2132[4]で説明されるように通常の可変長のオプションであるかのように集合オプションバッファにオプションのそれぞれの分裂部分を保存しなければなりません。 オプションのそれぞれの分裂部分の長さの分野はオプションデータの全長を意味しなければなりません。 分けられるどんな与えられたオプションにおいても、それぞれの分裂部分のオプションコード分野は同じであるに違いありません。
7. Decoding Agent Behavior
7. エージェントの振舞いを解読します。
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つ以上のオプションを見つけるとき、それは、それらが先行するセクションで説明されるようにオプションの分裂部分であると考えなければなりません。
Lemon & Cheshire Standards Track [Page 5] RFC 3396 Encoding Long Options in DHCPv4 November 2002
DHCPv4 November 2002の長いオプションをコード化するレモンとチェーシャー州標準化過程[5ページ]RFC3396
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.
解読しているエージェントが分裂オプションを見つけて、そのオプションのコンテンツをただ一つのオプションとして扱わなければなりません、そして、エージェントの振舞いをコード化する下で上で説明されたオーダーでコンテンツを組み立て直さなければなりません。
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.
オプションが分けられるところへのどんな意味意味もありません--コード化しているエージェントが任意な点で自由にオプションを分けることができて、解読しているエージェントは、分裂オプション一部を単一のオブジェクトに組み立て直さなければならなくて、オプションのそれぞれの分裂部分を別々のオブジェクトとして扱ってはいけません。
8. Example
8. 例
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:
オプションを考えてください、そして、Bootfileは"/diskless/foo"の値で(オプションコード67)を命名します。 通常、これは以下の通りただ一つのオプションとしてコード化されるでしょう:
+----+----+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 67 | 13 | / | d | i | s | k | l | e | s | s | / | f | o | o |
+----+----+---+---+---+---+---+---+---+---+---+---+---+---+---+
+----+----+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 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 | 7 | / | d| i| s| k| l| e| +----+---+---+---+---+---+---+---+---+
+----+---+---+---+---+---+---+---+
| 67 | 6 | s | s | / | f | o | o |
+----+---+---+---+---+---+---+---+
+----+---+---+---+---+---+---+---+ | 67 | 6 | s| s| / | f| o | o | +----+---+---+---+---+---+---+---+
9. Security Considerations
9. セキュリティ問題
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プロトコルで攻撃する潜在被曝はDHCPプロトコル仕様[3]のセクション7とDHCP Messages[5]のためのAuthenticationで論じられます。
Lemon & Cheshire Standards Track [Page 6] RFC 3396 Encoding Long Options in DHCPv4 November 2002
DHCPv4 November 2002の長いオプションをコード化するレモンとチェーシャー州標準化過程[6ページ]RFC3396
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の世代か検証の前の)に認証分野を設定するとき、そのような場合実装は慎重であるに違いありません。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Croft, W. and J. Gilmore, "BOOTSTRAP PROTOCOL (BOOTP)", RFC 951,
September 1985.
[1] 耕地とW.とJ.ギルモア、「プロトコル(BOOTP)を独力で進んでください」、RFC951、1985年9月。
[2] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
1997.
[3]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[4] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[4] アレクサンダーとS.とDroms、R.、「DHCPオプションとBOOTPベンダー拡大」、RFC2132、1997年3月。
10.2. Informative References
10.2. 有益な参照
[5] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC
3118, June 2001.
[5]DromsとR.とW.Arbaugh、「DHCPメッセージのための認証」、RFC3118、2001年6月。
11. Intellectual Property Statement
11. 知的所有権声明
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はどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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専務に情報を扱ってください。
Lemon & Cheshire Standards Track [Page 7] RFC 3396 Encoding Long Options in DHCPv4 November 2002
DHCPv4 November 2002の長いオプションをコード化するレモンとチェーシャー州標準化過程[7ページ]RFC3396
12. Authors' Addresses
12. 作者のアドレス
Ted Lemon Nominum, Inc. 2385 Bay Road Redwood City, CA 94043 USA
テッドレモンNominum Inc.2385湾のRoadカリフォルニア94043レッドウッドシティー(米国)
EMail: mellon@nominum.com
メール: mellon@nominum.com
Stuart Cheshire Apple Computer, Inc. 1 Infinite Loop Cupertino California 95014 USA
スチュアートチェーシャー州アップル・コンピューターInc.1無限ループカルパチーノカリフォルニア95014米国
Phone: +1 408 974 3207 EMail: rfc@stuartcheshire.org
以下に電話をしてください。 +1 3207年の408 974メール: rfc@stuartcheshire.org
Lemon & Cheshire Standards Track [Page 8] RFC 3396 Encoding Long Options in DHCPv4 November 2002
DHCPv4 November 2002の長いオプションをコード化するレモンとチェーシャー州標準化過程[8ページ]RFC3396
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Lemon & Cheshire Standards Track [Page 9]
レモンとチェーシャー州標準化過程[9ページ]
一覧
スポンサーリンク
