この文書はRFC3315の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group R. Droms, Ed.
Request for Comments: 3315 Cisco
Category: Standards Track J. Bound
Hewlett Packard
B. Volz
Ericsson
T. Lemon
Nominum
C. Perkins
Nokia Research Center
M. Carney
Sun Microsystems
July 2003
Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
ＩＰｖ６の動的ホスト設定プロトコル（ＤＨＣＰｖ６）
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.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
概要
The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP
servers to pass configuration parameters such as IPv6 network
addresses to IPv6 nodes. It offers the capability of automatic
allocation of reusable network addresses and additional configuration
flexibility. This protocol is a stateful counterpart to "IPv6
Stateless Address Autoconfiguration" (RFC 2462), and can be used
separately or concurrently with the latter to obtain configuration
parameters.
ＩＰｖ６のための動的ホスト設定プロトコル（ＤＨＣＰ）はＤＨＣＰサーバ
がＩＰｖ６ノードにＩＰｖ６ネットワークアドレスのような設定パラメータ
を渡すことができるようにします。これは再利用可能なネットワークアドレ
スと柔軟な自動割当て設定の能力を提供します。このプロトコルは「ＩＰｖ
６ステートレスアドレス自動設定」（ＲＦＣ２４６２）のステートフルに対
応するもので、設定パラメータを得るために同時にあるいは後で使われるこ
とができます。
Table of Contents
目次
1. Introduction and Overview
1. 導入と概観
1.1. Protocols and Addressing
1.1. プロトコルとアドレス
1.2. Client-server Exchanges Involving Two Messages
1.2. クライアント−サーバが２つのメッセージを交換します
1.3. Client-server Exchanges Involving Four Messages
1.3. クライアントサーバが４つのメッセージを交換
2. Requirements
2. 必要条件
3. Background
3. 背景
4. Terminology
4. 専門用語
4.1. IPv6 Terminology
4.1. ＩＰｖ６専門用語
4.2. DHCP Terminology
4.2. ＤＨＣＰ専門用語
5. DHCP Constants
5. ＤＨＣＰ定数
5.1. Multicast Addresses
5.1. マルチキャストアドレス
5.2. UDP Ports
5.2. ＵＤＰポート
5.3. DHCP Message Types
5.3. ＤＨＣＰメッセージタイプ
5.4. Status Codes
5.4. 状態コード
5.5. Transmission and Retransmission Parameters
5.5. 伝達と再送パラメータ
5.6. Representation of time values and "Infinity" as a time value
5.6. 時刻値と時刻値としての「無限」の表現
6. Client/Server Message Formats
6. クライアント／サーバメッセージフォーマット
7. Relay Agent/Server Message Formats
7. リレーエージェント／サーバーメッセージフォーマット
7.1. Relay-forward Message
7.1. リレー転送メッセージ
7.2. Relay-reply Message
7.2. リレー応答メッセージ
8. Representation and Use of Domain Names
8. ドメイン名の表現と使用
9. DHCP Unique Identifier (DUID)
9. ＤＨＣＰユニーク識別子（ＤＵＩＤ）
9.1. DUID Contents
9.1. ＤＵＩＤ中身
9.2. DUID Based on Link-layer Address Plus Time [DUID-LLT]
9.2. リンク層アドレスと時刻プラス時間に基づいたＤＵＩＤ[DUID-LLT]
9.3. DUID Assigned by Vendor Based on Enterprise Number [DUID-EN]
9.3. 企業番号に基づいてベンダによって割り当てられるＤＵＩＤ[DUID-EN]
9.4. DUID Based on Link-layer Address [DUID-LL]
9.4. リンク層アドレスに基づいたＤＵＩＤ[DUID-LL]
10. Identity Association
10. 識別子集団
11. Selecting Addresses for Assignment to an IA
11. ＩＡに割当てるアドレスの選択
12. Management of Temporary Addresses
12. 一時的なアドレス管理
13. Transmission of Messages by a Client
13. クライアントによるメッセージの伝達
14. Reliability of Client Initiated Message Exchanges
14. クライアントによって始められたメッセージ交換の信頼性
15. Message Validation
15. メッセージ検証
15.1. Use of Transaction IDs
15.1. 処理識別子の使用
15.2. Solicit Message
15.2. 要請メッセージ
15.3. Advertise Message
15.3. 広告メッセージ
15.4. Request Message
15.4. 要求メッセージ
15.5. Confirm Message
15.5. 確証メッセージ
15.6. Renew Message
15.6. 更新メッセージ
15.7. Rebind Message
15.7. 再結合メッセージ
15.8. Decline Messages
15.8. 辞退メッセージ
15.9. Release Message
15.9. 開放メッセージ
15.10. Reply Message
15.10. 応答メッセージ
15.11. Reconfigure Message
15.11. 再設定メッセージ
15.12. Information-request Message
15.12. 情報要求メッセージ
15.13. Relay-forward Message
15.13. リレー転送メッセージ
15.14. Relay-reply Message
15.14. リレー応答メッセージ
16. Client Source Address and Interface Selection
16. クライアントソースアドレスとインタフェース選択
17. DHCP Server Solicitation
17. ＤＨＣＰサーバ要請
17.1. Client Behavior
17.1. クライアント行動
17.1.1. Creation of Solicit Messages
17.1.1. 要請メッセージの生成
17.1.2. Transmission of Solicit Messages
17.1.2. 要請メッセージの伝達
17.1.3. Receipt of Advertise Messages
17.1.3. 広告メッセージの受信
17.1.4. Receipt of Reply Message
17.1.4. 応答メッセージ受信
17.2. Server Behavior
17.2. サーバ行動
17.2.1. Receipt of Solicit Messages
17.2.1. 要請メッセージの受信
17.2.2. Creation and Transmission of Advertise Messages
17.2.2. 広告メッセージの生成と伝達
17.2.3. Creation and Transmission of Reply Messages
17.2.3. 応答メッセージの生成と伝達
18. DHCP Client-Initiated Configuration Exchange
18. ＤＨＣＰクライアントによって始められた設定交換
18.1. Client Behavior
18.1. クライアント行動
18.1.1. Creation and Transmission of Request Messages
18.1.1. 要求メッセージの作成と伝達
18.1.2. Creation and Transmission of Confirm Messages
18.1.2. 各章メッセージの生成と伝達
18.1.3. Creation and Transmission of Renew Messages
18.1.3. 更新メッセージの送信と伝達
18.1.4. Creation and Transmission of Rebind Messages
18.1.4. 再結合メッセージの生成と伝達
18.1.5. Creation and Transmission of Information-request Messages
18.1.5. 情報要求メッセージの生成と伝達
18.1.6. Creation and Transmission of Release Messages
18.1.6. 開放メッセージの生成と伝達
18.1.7. Creation and Transmission of Decline Messages
18.1.7 辞退メッセージの生成と伝達
18.1.8. Receipt of Reply Messages
18.1.8. 応答メッセージ受信
18.2. Server Behavior
18.2. サーバ行動
18.2.1. Receipt of Request Messages
18.2.1. 要求メッセージの受信
18.2.2. Receipt of Confirm Messages
18.2.2. 確証メッセージ受信
18.2.3. Receipt of Renew Messages
18.2.3. 更新メッセージ受信
18.2.4. Receipt of Rebind Messages
18.2.4. 再結合メッセージの受信
18.2.5. Receipt of Information-request Messages
18.2.5. 情報要求の受信
18.2.6. Receipt of Release Messages
18.2.6. 開放メッセージ受信
18.2.7. Receipt of Decline Messages
18.2.7. 辞退メッセージの受信
18.2.8. Transmission of Reply Messages
18.2.8. 応答メッセージの伝達
19. DHCP Server-Initiated Configuration Exchange
19. ＤＨＣＰサーバからはじめる設定交換
19.1. Server Behavior
19.1. サーバ動作
19.1.1. Creation and Transmission of Reconfigure Messages
19.1.1. 再設定メッセージの生成と伝達
19.1.2. Time Out and Retransmission of Reconfigure Messages
19.1.2. タイムアウトと再設定メッセージの再送
19.2. Receipt of Renew Messages
19.2. 更新メッセージの受信
19.3. Receipt of Information-request Messages
19.3. 情報要求メッセージの受信
19.4. Client Behavior
19.4. クライアント動作
19.4.1. Receipt of Reconfigure Messages
19.4.1. 再設定メッセージの受信
19.4.2. Creation and Transmission of Renew Messages
19.4.2. 更新メッセージの生成と伝達
19.4.3. Creation and Transmission of Information-request Messages
19.4.3. 情報要求メッセージの生成と伝達
19.4.4. Time Out and Retransmission of Renew or Information-request Messages
19.4.4. タイムアウトと更新や情報要求メッセージの再送
19.4.5. Receipt of Reply Messages
19.4.5. 応答メッセージの受信
20. Relay Agent Behavior
20. リレーエージェント動作
20.1. Relaying a Client Message or a Relay-forward Message
20.1. クライアントメッセージやリレー転送メッセージの中継
20.1.1. Relaying a Message from a Client
20.1.1. クライアントからのメッセージの中継
20.1.2. Relaying a Message from a Relay Agent
20.1.2. リレーエージェントからの中継メッセージ
20.2. Relaying a Relay-reply Message
20.2. リレー応答メッセージの中継
20.3. Construction of Relay-reply Messages
20.3. リレー応答メッセージの生成
21. Authentication of DHCP Messages
21. ＤＨＣＰメッセージ認証
21.1. Security of Messages Sent Between Servers and Relay Agents
21.1. サーバとリレーエージェント間で送られるメッセージのセキュリティ
21.2. Summary of DHCP Authentication
21.2. ＤＨＣＰ認証の要約
21.3. Replay Detection
21.3. 再生攻撃発見
21.4. Delayed Authentication Protocol
21.4. 遅延認証プロトコル
21.4.1. Use of the Authentication Option in the Delayed Authentication Protocol
21.4.1. 遅延認証プロトコルでの認証オプションの使用法
21.4.2. Message Validation
21.4.2. メッセージ検証
21.4.3. Key Utilization
21.4.3. 鍵使用
21.4.4. Client Considerations for Delayed Authentication Protocol
21.4.4. 遅延認証プロトコルに対するクライアント考慮
21.4.5. Server Considerations for Delayed Authentication Protocol
21.4.5. 遅延認証プロトコルに対するサーバの考慮
21.5. Reconfigure Key Authentication Protocol
21.5. 再設定鍵認証プロトコル
21.5.1. Use of the Authentication Option in the Reconfigure Key Authentication Protocol
21.5.1. 再設定鍵認証プロトコルでの認証オプションの使用
21.5.2. Server considerations for Reconfigure Key protocol
21.5.2. 再設定鍵プロトコルに対するサーバの考慮
21.5.3. Client considerations for Reconfigure Key protocol
21.5.3. 再設定鍵プロトコルに対するクライアントの考慮
22. DHCP Options
22. ＤＨＣＰオプション
22.1. Format of DHCP Options
22.1. ＤＨＣＰオプションのフォーマット
22.2. Client Identifier Option
22.2. クライアント識別子オプション
22.3. Server Identifier Option
22.3. サーバ識別子オプション
22.4. Identity Association for Non-temporary Addresses Option
22.4. 非臨時アドレス識別子集団オプション
22.5. Identity Association for Temporary Addresses Option
22.5. 一時的アドレスオプション識別子集団
22.6. IA Address Option
22.6. ＩＡアドレスオプション
22.7. Option Request Option
22.7. オプション要求オプション
22.8. Preference Option
22.8. 優先オプション
22.9. Elapsed Time Option
22.9. 経過時間オプション
22.10. Relay Message Option
22.10. リレーメッセージオプション
22.11. Authentication Option
22.11. 認証オプション
22.12. Server Unicast Option
22.12. サーバーユニキャストオプション
22.13. Status Code Option
22.13. 状態コードオプション
22.14. Rapid Commit Option
22.14. 即時委任オプション
22.15. User Class Option
22.15. ユーザクラスオプション
22.16. Vendor Class Option
22.16. ベンダークラスオプション
22.17. Vendor-specific Information Option
22.17. ベンダ固有の情報オプション
22.18. Interface-Id Option
22.18. インタフェース識別子オプション
22.19. Reconfigure Message Option
22.19. 再設定メッセージオプション
22.20. Reconfigure Accept Option
22.20. 再設定受入オプション
23. Security Considerations
23. セキュリティの考慮
24. IANA Considerations
24. ＩＡＮＡの考慮
24.1. Multicast Addresses
24.1. マルチキャストアドレス
24.2. DHCP Message Types
24.2. ＤＨＣＰメッセージタイプ
24.3. DHCP Options
24.3. ＤＨＣＰオプション
24.4. Status Codes
24.4. 状態コード
24.5. DUID
24.5. ＤＵＩＤ
25. Acknowledgments
25. 謝辞
26. References
26. 参考文献
26.1. Normative References
26.1. 参照する参考文献
26.2. Informative References
26.2. 有益な参考文献
A. Appearance of Options in Message Types
A. メッセージタイプでのオプションの存在
B. Appearance of Options in the Options Field of DHCP Options
B. ＤＨＣＰオプションのオプションフィールドの中のオプションの存在
Chair's Address
議長のアドレス
Authors' Addresses
著者のアドレス
Full Copyright Statement
著作権表示全文
1. Introduction and Overview
1. 導入と概観
This document describes DHCP for IPv6 (DHCP), a client/server
protocol that provides managed configuration of devices.
この文書はＩＰｖ６で管理された装置設定を供給するクライアント／サーバ・
プロトコルであるＤＨＣＰを記述します。
DHCP can provide a device with addresses assigned by a DHCP server
and other configuration information, which are carried in options.
DHCP can be extended through the definition of new options to carry
configuration information not specified in this document.
ＤＨＣＰは、ＤＨＣＰサーバによって割り当てられたアドレスと、オプショ
ンで運ばれる他の設定情報を装置に提供することができます。ＤＨＣＰはこ
の文書で指定しない設定情報を運ぶために、新しいオプションの定義を通し
て、拡張ができます。
DHCP is the "stateful address autoconfiguration protocol" and the
"stateful autoconfiguration protocol" referred to in "IPv6 Stateless
Address Autoconfiguration" [17].
ＤＨＣＰは「ステートフルアドレス自動設定プロトコル」で、「ＩＰｖ６ス
テートレスアドレス自動設定」[17]で参照される「ステートフル自動設定プ
ロトコル」です。
The operational models and relevant configuration information for
DHCPv4 [18][19] and DHCPv6 are sufficiently different that
integration between the two services is not included in this
document. If there is sufficient interest and demand, integration
can be specified in a document that extends DHCPv6 to carry IPv4
addresses and configuration information.
ＤＨＣＰｖ４[18][19]とＤＨＣＰｖ６の運用モデルと適切な設定情報が異なっ
ているので、２つのサービス間の統合がこの文書に含まれなません。もし十
分な興味と要求があるなら、ＩＰｖ４アドレスと設定情報を運ぶためのＤＨ
ＣＰｖ６拡張をする文書を指定することができます。
The remainder of this introduction summarizes DHCP, explaining the
message exchange mechanisms and example message flows. The message
flows in sections 1.2 and 1.3 are intended as illustrations of DHCP
operation rather than an exhaustive list of all possible
client-server interactions. Sections 17, 18, and 19 explain client
and server operation in detail.
この導入の残りで、メッセージ交換機構とメッセージの流れの例を説明し、
ＤＨＣＰを要約します。１.２章と１.３章のメッセージの流れは、クライア
ント・サーバ対話のすべての可能な完全リストではなく、ＤＨＣＰオペレー
ションの例を意図します。１７章と１８と１９章がクライアントとサーバー
オペレーションの詳細を説明します。
1.1. Protocols and Addressing
1.1. プロトコルとアドレス
Clients and servers exchange DHCP messages using UDP [15]. The
client uses a link-local address or addresses determined through
other mechanisms for transmitting and receiving DHCP messages.
クライアントとサーバがＵＤＰ[19]を使っているＤＨＣＰメッセージを交換
します。クライアントは他のメカニズムにより決定したリンクローカルアド
レスを、ＤＨＣＰメッセージを送受信するために使います。
DHCP servers receive messages from clients using a reserved,
link-scoped multicast address. A DHCP client transmits most messages
to this reserved multicast address, so that the client need not be
configured with the address or addresses of DHCP servers.
ＤＨＣＰサーバがリンク範囲のマルチキャストアドレスを使っているクライ
アントからメッセージを受け取ります。ＤＨＣＰクライアントがたいていの
この予約のマルチキャストアドレスへメッセージを伝達します、それでクラ
イアントにＤＨＣＰサーバのアドレスを設定する必要がありません。
To allow a DHCP client to send a message to a DHCP server that is not
attached to the same link, a DHCP relay agent on the client's link
will relay messages between the client and server. The operation of
the relay agent is transparent to the client and the discussion of
message exchanges in the remainder of this section will omit the
description of message relaying by relay agents.
ＤＨＣＰクライアントと同じリンクにはないＤＨＣＰサーバにメッセージを
送ることを許すために、クライアントのリンク上のＤＨＣＰリレーエージェ
ントがクライアントとサーバの間のメッセージを中継するでしょう。リレー
エージェントの運用はクライアントに透過です、そしてこの章の残りでのメッ
セージ交換の論議はリレーエージェントによってメッセージを中継すること
の記述をしないでしょう。
Once the client has determined the address of a server, it may under
some circumstances send messages directly to the server using
unicast.
クライアントがサーバのアドレスを決定したら、ある状況下で直接ユニキャ
ストを使ってサーバにメッセージを送るかもしれません。
1.2. Client-server Exchanges Involving Two Messages
1.2. クライアント−サーバが２つのメッセージを交換します
When a DHCP client does not need to have a DHCP server assign it IP
addresses, the client can obtain configuration information such as a
list of available DNS servers [20] or NTP servers [21] through a
single message and reply exchanged with a DHCP server. To obtain
configuration information the client first sends an
Information-Request message to the All_DHCP_Relay_Agents_and_Servers
multicast address. Servers respond with a Reply message containing
the configuration information for the client.
ＤＨＣＰクライアントがＤＨＣＰサーバにＩＰアドレスを割り当てを要求し
ない時、クライアントはＤＨＣＰサーバと１つのメッセージと応答の交換で、
利用可能なＤＮＳサーバ[20]やＮＴＰサーバ[21]リストのような設定情報を
得ることができます。設定情報を得るために、クライアントは最初に情報要
求メッセージを全ＤＨＣＰリレーエージェントアンドサーバマルチキャスト
アドレスに送ります。サーバが応答メッセージにクライアントの設定情報を
含めて、返します。
This message exchange assumes that the client requires only
configuration information and does not require the assignment of any
IPv6 addresses.
このメッセージ交換はクライアントが設定情報だけを必要とし、ＩＰｖ６ア
ドレス割当てを要求しないと想定します。
When a server has IPv6 addresses and other configuration information
committed to a client, the client and server may be able to complete
the exchange using only two messages, instead of four messages as
described in the next section. In this case, the client sends a
Solicit message to the All_DHCP_Relay_Agents_and_Servers requesting
the assignment of addresses and other configuration information.
This message includes an indication that the client is willing to
accept an immediate Reply message from the server. The server that
is willing to commit the assignment of addresses to the client
immediately responds with a Reply message. The configuration
information and the addresses in the Reply message are then
immediately available for use by the client.
クライアントに委託するＩＰｖ６アドレスと他の設定情報をサーバが持つ時、
クライアントとサーバは、次章で記述されるように、４つのメッセージの代
わりに２つメッセージだけを使い、交換を完了することが可能であるかもし
れません。この場合、クライアントはアドレスと他の設定情報の割当ての要
求のため、全ＤＨＣＰリレーエージェントアンドサーバへの要請メッセージ
を送ります。このメッセージはクライアントがサーバから直接応答メッセー
ジを受信してよいという表示を含みます。クライアントにすぐにアドレスの
割当てをするサーバは応答メッセージで返答します。応答メッセージ内の設
定情報とアドレスはクライアントにすぐに使用可能です。
Each address assigned to the client has associated preferred and
valid lifetimes specified by the server. To request an extension of
the lifetimes assigned to an address, the client sends a Renew
message to the server. The server sends a Reply message to the
client with the new lifetimes, allowing the client to continue to use
the address without interruption.
各クライアントに割り当てられたアドレスは、サーバに指定された優先度と
正式な寿命が関連づけられます。割当てられたアドレスの寿命の延長を求め
るために、クライアントはサーバに更新メッセージを送ります。サーバはク
ライアントに新しい寿命の応答メッセージを送り、クライアントは中断無し
でアドレスを使い続けることができます。
1.3. Client-server Exchanges Involving Four Messages
1.3. クライアントサーバが４つのメッセージを交換
To request the assignment of one or more IPv6 addresses, a client
first locates a DHCP server and then requests the assignment of
addresses and other configuration information from the server. The
client sends a Solicit message to the
All_DHCP_Relay_Agents_and_Servers address to find available DHCP
servers. Any server that can meet the client's requirements responds
with an Advertise message. The client then chooses one of the
servers and sends a Request message to the server asking for
confirmed assignment of addresses and other configuration
information. The server responds with a Reply message that contains
the confirmed addresses and configuration.
１つ以上のＩＰｖ６アドレスの割当てを求めるために、クライアントが最初
にＤＨＣＰサーバの場所を突き止め、そして次にサーバからアドレスと他の
設定情報の割当てを求めます。クライアントは利用可能なＤＨＣＰサーバを
見いだすために全ＤＨＣＰリレーアンドサーバアドレスに要求メッセージを
送ります。クライアントの条件を満たすことができるサーバは広告メッセー
ジで返答します。クライアントはサーバの１つを選択し、そしてアドレスと
他設定情報の確認された割当てを求めてサーバにリクエストメッセージを送
ります。サーバは確認されたアドレスと設定を含む応答メッセージで返答し
ます。
As described in the previous section, the client sends a Renew
message to the server to extend the lifetimes associated with its
addresses, allowing the client to continue to use those addresses
without interruption.
前の章で記述されるように、クライアントは、クライアントが中断無しでそ
れらのアドレスを使い続けることを許し、そのアドレスと結び付いた寿命を
延長するために、サーバに更新メッセージを送ります。
2. Requirements
2. 必要条件
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [1].
キーワードMUSTとMUST NOTとREQUIREDとSHALLとSHALL NOTとSHOULDとSHOULD
NOTとRECOMMENDEDとMAYとOPTIONALがこの文書に現われる時、は[1]で記述さ
れるように解釈さます。
This document also makes use of internal conceptual variables to
describe protocol behavior and external variables that an
implementation must allow system administrators to change. The
specific variable names, how their values change, and how their
settings influence protocol behavior are provided to demonstrate
protocol behavior. An implementation is not required to have them in
the exact form described here, so long as its external behavior is
consistent with that described in this document.
この文書はプロトコル動作を記述するために内部の概念的な変数を利用し、
実装がシステム管理者に変えることを許す外部の変数を使います。特定の変
数名は、その値を変更する方法とその設定がプロトコル行動に与える影響を
説明するために供給されます。実装は外部動作がこの文書で記述されている
ものと整合する限り、ここで記述された、正確な形式で変数を持つようには
要求されません。
3. Background
3. 背景
The IPv6 Specification provides the base architecture and design of
IPv6. Related work in IPv6 that would best serve an implementor to
study includes the IPv6 Specification [3], the IPv6 Addressing
Architecture [5], IPv6 Stateless Address Autoconfiguration [17], IPv6
Neighbor Discovery Processing [13], and Dynamic Updates to DNS [22].
These specifications enable DHCP to build upon the IPv6 work to
provide both robust stateful autoconfiguration and autoregistration
of DNS Host Names.
ＩＰｖ６仕様書はＩＰｖ６の基礎アーキテクチャとデザインを供給します。
実装者が勉強するために最も良いＩＰｖ６に関連した仕事が、ＩＰｖ６仕様
書[3]と、ＩＰｖ６アドレス体系[5]と、ＩＰｖ６ステートレスアドレス自動
設定[17]と、ＩＰｖ６近隣探索処理[13]と、動的ＤＮＳ更新[22]です。これ
らの仕様書はＤＨＣＰがＩＰｖ６の仕事の上で強靭なステートフル自動設定
とＤＮＳホスト名の自動設定の両方を供給することができるようにします。
The IPv6 Addressing Architecture specification [5] defines the
address scope that can be used in an IPv6 implementation, and the
various configuration architecture guidelines for network designers
of the IPv6 address space. Two advantages of IPv6 are that support
for multicast is required and nodes can create link-local addresses
during initialization. The availability of these features means that
a client can use its link-local address and a well-known multicast
address to discover and communicate with DHCP servers or relay agents
on its link.
ＩＰｖ６アドレス体系仕様書[5]はＩＰｖ６実装が使えるアドレス範囲と、Ｉ
Ｐｖ６アドレス空間のネットワーク設計の様々な設定体系ガイドラインを定
義します。ＩＰｖ６の２つの利点がマルチキャストに対するサポートが必要
な事と、ノードが初期化の際にリンクローカルアドレスを作ることができる
ということです。これらの特徴の有効性はクライアントがそのリンクローカ
ルアドレスと既知マルチキャストアドレスを使って、リンク上にＤＨＣＰサー
バかリレーエージェントを発見し通信できることです。
IPv6 Stateless Address Autoconfiguration [17] specifies procedures by
which a node may autoconfigure addresses based on router
advertisements [13], and the use of a valid lifetime to support
renumbering of addresses on the Internet. In addition, the protocol
interaction by which a node begins stateless or stateful
autoconfiguration is specified. DHCP is one vehicle to perform
stateful autoconfiguration. Compatibility with stateless address
autoconfiguration is a design requirement of DHCP.
ＩＰｖ６ステートレスアドレス自動設定[17]はノードがルータ広告[13]に基
づいてアドレスを自動設定する手順とインターネット上でアドレスリナンバ
リングをサポートするための正式な寿命の使用を指定します。加えて、ノー
ドがステートレスあるいはステートフル自動設定を始めるプロトコル対話が
指定されます。ＤＨＣＰはステートフル自動設定を行う１つの手段です。ス
テートレスアドレス自動設定との互換性はＤＨＣＰのデザイン条件です。
IPv6 Neighbor Discovery [13] is the node discovery protocol in IPv6
which replaces and enhances functions of ARP [14]. To understand
IPv6 and stateless address autoconfiguration, it is strongly
recommended that implementors understand IPv6 Neighbor Discovery.
ＩＰｖ６近隣探索[13]はＡＲＰ[14]機能を置き換えて拡張するＩＰｖ６での
ノード探索プロトコルです。ＩＰｖ６とステートレスアドレス自動設定を理
解するために、実装者がＩＰｖ６近隣探索を理解することは強く勧められま
す。
Dynamic Updates to DNS [22] is a specification that supports the
dynamic update of DNS records for both IPv4 and IPv6. DHCP can use
the dynamic updates to DNS to integrate addresses and name space to
not only support autoconfiguration, but also autoregistration in
IPv6.
ＤＮＳの動的更新[22]はＩＰｖ４とＩＰｖ６の両方のためにＤＮＳレコード
の動的更新をサポートする仕様書です。ＤＨＣＰはアドレスと名前空間を統
合し、自動設定をサポートするだけではなく、ＩＰｖ６の自動設定のために、
ＤＮＳ動的更新を使うことができます。
4. Terminology
4. 専門用語
This sections defines terminology specific to IPv6 and DHCP used in
this document.
これ章はこの文書で使うＩＰｖ６とＤＨＣＰに特有な専門用語を定義します。
4.1. IPv6 Terminology
4.1. ＩＰｖ６専門用語
IPv6 terminology relevant to this specification from the IPv6
Protocol [3], IPv6 Addressing Architecture [5], and IPv6 Stateless
Address Autoconfiguration [17] is included below.
ＩＰｖ６プロトコル[3]とＩＰｖ６アドレス体系[5]とＩＰｖ６ステートレス
アドレス自動設定[17]の仕様書に関係があるＩＰｖ６専門用語が下に含まれ
ます。
address An IP layer identifier for an interface
or a set of interfaces.
アドレス インタフェースやインタフェース集合のＩＰ
レイヤ識別子。
host Any node that is not a router.
ホスト ルータでないノード。
IP Internet Protocol Version 6 (IPv6). The
terms IPv4 and IPv6 are used only in
contexts where it is necessary to avoid
ambiguity.
ＩＰ インターネットプロトコルバージョン６。用
語ＩＰｖ４とＩＰｖ６はあいまい性を避ける
ことは必要である場合にだけ使われます。
interface A node's attachment to a link.
インタフェース ノードのリンクへの接続装置。
link A communication facility or medium over
which nodes can communicate at the link
layer, i.e., the layer immediately
below IP. Examples are Ethernet (simple
or bridged); Token Ring; PPP links,
X.25, Frame Relay, or ATM networks; and
Internet (or higher) layer "tunnels",
such as tunnels over IPv4 or IPv6
itself.
リンク リンク層で、ノードがその上で通信する通信
機能あるいは媒体、すなわち、ＩＰの直下の
レイヤ。例はイーサネット（単純なもの、あ
るいはブリッジしたもの）；トークンリング；
ＰＰＰリンク、Ｘ．２５、フレームリレー、
ＡＴＭネットワーク；インターネット（ある
いは更に上）の「トンネル」、例えばＩＰｖ
４上のトンネルやＩＰｖ６自身の上のトンネ
ル。
link-layer identifier A link-layer identifier for an
interface. Examples include IEEE 802
addresses for Ethernet or Token Ring
network interfaces, and E.164 addresses
for ISDN links.
リンク層識別子 インタフェースのリンクレイヤ識別子。例え
ばイーサネットやトークンリング・ネットワー
クインタフェースのＩＥＥＥ８０２アドレス
や、ＩＳＤＮリンクのＥ.１６４アドレス。
link-local address An IPv6 address having a link-only
scope, indicated by having the prefix
(FE80::/10), that can be used to reach
neighboring nodes attached to the same
link. Every interface has a link-local
address.
リンクローカルアドレス 同じリンクの隣接ノードに達するために使う
ことができるプレフィックス(FE80::/10)を
持つことで示される、リンクのみの範囲を持
つＩＰｖ６アドレス。すべてのインタフェー
スがリンクローカルアドレスを持っています。
multicast address An identifier for a set of interfaces
(typically belonging to different
nodes). A packet sent to a multicast
address is delivered to all interfaces
identified by that address.
マルチキャストアドレス （典型的に異なったノードに属している）イ
ンタフェース集合のための識別子。マルチキャ
ストアドレスに送られたパケットがすべての
そのアドレスによって識別されたインタフェー
スに配達されます。
neighbor A node attached to the same link.
近隣 同じリンク上のノード。
node A device that implements IP.
ノード ＩＰを実行する装置。
packet An IP header plus payload.
パケット ＩＰヘッダとペイロード。
prefix The initial bits of an address, or a
set of IP addresses that share the same
initial bits.
プレフィックス アドレスの最初のビット、あるいは最初のビッ
トを共有するＩＰアドレスの集合。
prefix length The number of bits in a prefix.
プレフィックス長 プレフィックスでのビット数。
router A node that forwards IP packets not
explicitly addressed to itself.
ルータ 明示的に自分宛てでないＩＰパケットを転送
するノード。
unicast address An identifier for a single interface.
A packet sent to a unicast address is
delivered to the interface identified by
that address.
ユニキャストアドレス ひとつのインタフェースのための識別子。ユ
ニキャストアドレスに送られたパケットがそ
のアドレスによって識別されたインタフェー
スに配達されます。
4.2. DHCP Terminology
4.2. ＤＨＣＰ専門用語
Terminology specific to DHCP can be found below.
ＤＨＣＰに特有の専門用語が下記の通りです。
appropriate to the link An address is "appropriate to the link"
when the address is consistent with the
DHCP server's knowledge of the network
topology, prefix assignment and address
assignment policies.
リンクに適切 アドレスがＤＨＣＰサーバの、ネットワーク
トポロジーとプレフィックス割当てとアドレ
ス割当てポリシーの知識と整合性がある時、
アドレスが「リンクに適切」です。
binding A binding (or, client binding) is a
group of server data records containing
the information the server has about
the addresses in an IA or configuration
information explicitly assigned to the
client. Configuration information that
has been returned to a client through a
policy - for example, the information
returned to all clients on the same
link - does not require a binding. A
binding containing information about
an IA is indexed by the tuple <DUID,
IA-type, IAID> (where IA-type is the
type of address in the IA; for example,
temporary). A binding containing
configuration information for a client
is indexed by <DUID>.
結合 結合（あるいは、クライアント結合）は、サー
バが持つ明示的にクライアントに割り当てら
れたＩＡのアドレスや設定情報に関する情報
を含んできいる、サーバデータレコードのグ
ループです。ポリシーを通してクライアント
に返された設定情報は−例えば、同じリンク
上のすべてのクライアントに返した情報は−
結合を必要としません。ＩＡについての情報
を含む結合が３項組み＜ＤＵＩＤ、ＩＡ種別、
ＩＡＩＤ＞で索引を付けられます（ＩＡ−タ
イプはＩＡアドレスのタイプです；例えば、
一時的）。クライアントの設定情報を含む結
合が＜ＤＵＩＤ＞で索引を付けられます。
configuration parameter An element of the configuration
information set on the server and
delivered to the client using DHCP.
Such parameters may be used to carry
information to be used by a node to
configure its network subsystem and
enable communication on a link or
internetwork, for example.
設定パラメータ 設定情報の要素がサーバに設定され、クライ
アントにＤＨＣＰで配達します。このような
パラメータは、ノードがネットワークサブシ
ステムの構成を設定し、例えばリンクあるい
はインターネット上で通信を可能にするため
に使われる情報を運ぶために、使われるかも
しれません。
DHCP Dynamic Host Configuration Protocol
for IPv6. The terms DHCPv4 and DHCPv6
are used only in contexts where it is
necessary to avoid ambiguity.
ＤＨＣＰ ＩＰｖ６のための動的ホスト設定プロトコル。
用語ＤＨＣＰｖ４とＤＨＣＰｖ６があいまい
性を避けることは必要である文脈でだけ使わ
れます。
DHCP client (or client) A node that initiates requests on a link
to obtain configuration parameters from
one or more DHCP servers.
ＤＨＣＰクライアント（あるいはクライアント） １つ以上のＤＨＣＰ
サーバか設定パラメータを得る要請をリンク
上で始めるノード。
DHCP domain A set of links managed by DHCP and
operated by a single administrative
entity.
ＤＨＣＰドメイン ＤＨＣＰによって管理され、ひとつの管理主
体によって運用されるリンクの集合。
DHCP realm A name used to identify the DHCP
administrative domain from which a DHCP
authentication key was selected.
ＤＨＣＰ領域 ＤＨＣＰ管理ドメインを識別する名前で、こ
こでＤＨＣＰ認証鍵が選択されます。
DHCP relay agent (or relay agent) A node that acts as an
intermediary to deliver DHCP messages
between clients and servers, and is on
the same link as the client.
ＤＨＣＰリレーエージェント（あるいはリレーエージェント） クライア
ントとサーバの間でＤＨＣＰメッセージを届
ける中間者役を務めて、そしてクライアント
と同じリンク上にあるノード。
DHCP server (or server) A node that responds to requests from
clients, and may or may not be on the
same link as the client(s).
ＤＨＣＰサーバ（あるいはサーバ） クライアントから要請に返答し、ク
ライアントと同じリンクの上にあるかもしれ
ないし、ないかもしれない、ノード。
DUID A DHCP Unique IDentifier for a DHCP
participant; each DHCP client and server
has exactly one DUID. See section 9 for
details of the ways in which a DUID may
be constructed.
ＤＵＩＤ ＤＨＣＰ関係者のためのＤＨＣＰユニーク識
別子；各ＤＨＣＰクライアントとサーバが正
確に１つのＤＵＩＤを持っています。ＤＵＩ
Ｄが生成されるかもしれない方法の細部は９
章を見てください。
Identity association (IA) A collection of addresses assigned to
a client. Each IA has an associated
IAID. A client may have more than one
IA assigned to it; for example, one for
each of its interfaces.
Each IA holds one type of address;
for example, an identity association
for temporary addresses (IA_TA) holds
temporary addresses (see "identity
association for temporary addresses").
Throughout this document, "IA" is used
to refer to an identity association
without identifying the type of
addresses in the IA.
識別子集団（ＩＡ） クライアントに割り当てられたアドレスの集
合。各ＩＡがＩＡＩＤを持っています。クラ
イアントがＩＡが割当てられた複数のＩＡを
持つかもしれません；例えば、各インター
フェース毎に。各ＩＡは１種類のアドレスを
持ちます；例えば、一時的アドレスの識別子
集団（ＩＡ＿ＴＡ）が一時的なアドレスを持
ちます（「一時的アドレスの識別関係」参照）。
この文書を通じて「ＩＡ」は、ＩＡのアドレ
ス種別を明示せずに識別子集団を言うために、
使われます。
Identity association identifier (IAID) An identifier for an IA,
chosen by the client. Each IA has an
IAID, which is chosen to be unique among
all IAIDs for IAs belonging to that
client.
識別子集団識別子（ＩＡＩＤ） クライアントによって選択されて、ＩＡ
の識別子。各ＩＡがＩＡＩＤを持ち、そして
ＩＡがそのクライアントに属するすべてのＩ
ＡＩＤ間で一意であるように選ばれます。
Identity association for non-temporary addresses (IA_NA) An IA
that carries assigned addresses that are
not temporary addresses (see "identity
association for temporary addresses")
非一時的アドレス（ＩＡ＿ＮＡ）識別子集団 一時的なアドレスではない
割当てられたアドレスを運ぶＩＡ（「一時的
なアドレスの識別関係」を参照）。
Identity association for temporary addresses (IA_TA) An IA that
carries temporary addresses (see RFC
3041 [12]).
一時的なアドレス（ＩＡ＿ＴＡ）識別子集団 一時的なアドレスを運ぶＩ
Ａ（ＲＦＣ３０４１[12]参照）。
message A unit of data carried as the payload
of a UDP datagram, exchanged among DHCP
servers, relay agents and clients.
メッセージ ＤＨＣＰサーバとリレーエージェントとクラ
イアント間で交換され、ＵＤＰデータグラム
のペイロードとして運ばれたデータユニット。
Reconfigure key A key supplied to a client by a server
used to provide security for Reconfigure
messages.
再設定鍵 サーバからクライアントに供給された鍵で、
再設定メッセージにセキュリティを提供する
もの。
relaying A DHCP relay agent relays DHCP messages
between DHCP participants.
中継 ＤＨＣＰリレーエージェントがＤＨＣＰ関係
者の間のＤＨＣＰメッセージを中継します。
transaction ID An opaque value used to match responses
with replies initiated either by a
client or server.
取引識別子 クライアントあるいはサーバに応答する際の
一致のための不透明な値。
5. DHCP Constants
5. ＤＨＣＰ定数
This section describes various program and networking constants used
by DHCP.
この章はＤＨＣＰによって使われた種々なプログラムとネットワーキング定
数を記述します。
5.1. Multicast Addresses
5.1. マルチキャストアドレス
DHCP makes use of the following multicast addresses:
ＤＨＣＰは次のマルチキャストアドレスを利用します：
All_DHCP_Relay_Agents_and_Servers (FF02::1:2) A link-scoped
multicast address used by a client to communicate with
neighboring (i.e., on-link) relay agents and servers.
All servers and relay agents are members of this
multicast group.
全ＤＨＣＰリレーエージェントアンドサーバ(FF02::1:2) 隣接する(すな
わちリンク上の）リレーエージェントとサーバと通信するた
めにクライアントによって使われるリンク範囲マルチキャス
トアドレス。すべてのサーバとリレーエージェントはこのマ
ルチキャストグループのメンバーです。
All_DHCP_Servers (FF05::1:3) A site-scoped multicast address used
by a relay agent to communicate with servers, either
because the relay agent wants to send messages to
all servers or because it does not know the unicast
addresses of the servers. Note that in order for
a relay agent to use this address, it must have an
address of sufficient scope to be reachable by the
servers. All servers within the site are members of
this multicast group.
全ＤＨＣＰサーバ(FF05::1:3) サーバと通信するリレーエージェントが
すべてのサーバにメッセージを送ることを望むか、あるいは
サーバのユニキャストアドレスを知らないため使う、サイト
範囲マルチキャストアドレス。リレーエージェントがこのア
ドレスを使うために、サーバに到達可能な十分な範囲のアド
レスを持っていなくてはならないことに注意してください。
すべてのサイト内のサーバはこのマルチキャストグループの
メンバです。
5.2. UDP Ports
5.2. ＵＤＰポート
Clients listen for DHCP messages on UDP port 546. Servers and relay
agents listen for DHCP messages on UDP port 547.
クライアントがＵＤＰポート５４６上でＤＨＣＰメッセージを待ちます。サー
バとリレーのエージェントがＵＤＰポート５４７でＤＨＣＰメッセージを待
ちます。
5.3. DHCP Message Types
5.3. ＤＨＣＰメッセージタイプ
DHCP defines the following message types. More detail on these
message types can be found in sections 6 and 7. Message types not
listed here are reserved for future use. The numeric encoding for
each message type is shown in parentheses.
ＤＨＣＰは次のメッセージタイプを定義します。これらのメッセージタイプ
のより多くの細部は６章と７章で見いだされます。ここでリストアップされ
ないメッセージタイプが将来の使用のために確保されます。各メッセージタ
イプの番号コーディングは括弧で示されます。
SOLICIT (1) A client sends a Solicit message to locate
servers.
要請(1) クライアントがサーバの場所を突き止める要請メッ
セージを送信します。
ADVERTISE (2) A server sends an Advertise message to indicate
that it is available for DHCP service, in
response to a Solicit message received from a
client.
広告(2) クライアントから受信した要請メッセージに応えて、
サーバがＤＨＣＰサービスで利用可能であることを
示す広告メッセージを送ります。
REQUEST (3) A client sends a Request message to request
configuration parameters, including IP
addresses, from a specific server.
要求(3) クライアントが、特定のサーバのＩＰアドレスを含
む、設定パラメータを要求する要求メッセージを送
ります。
CONFIRM (4) A client sends a Confirm message to any
available server to determine whether the
addresses it was assigned are still appropriate
to the link to which the client is connected.
確証(4) クライアントが割り当てられたアドレスがクライア
ントが接続されているリンクにまだ適切であるかど
うか決定するために利用可能なサーバに確証メッセー
ジを送ります。
RENEW (5) A client sends a Renew message to the server
that originally provided the client's addresses
and configuration parameters to extend the
lifetimes on the addresses assigned to the
client and to update other configuration
parameters.
更新(5) クライアントが、クライアントに割り当てられたア
ドレスの寿命を延ばし、そして他の設定パラメータ
を更新するために、クライアントのアドレスと設定
パラメータを供給したサーバに更新メッセージを送
ります。
REBIND (6) A client sends a Rebind message to any
available server to extend the lifetimes on the
addresses assigned to the client and to update
other configuration parameters; this message is
sent after a client receives no response to a
Renew message.
再結合(6) クライアントがクライアントに割り当てられたアド
レスの寿命を延長して、そして他の設定パラメータ
を更新するために利用可能なサーバに再結合メッセー
ジを送ります；このメッセージは、クライアントが
更新メッセージに対する応答を受け取らなかった後
で、送られます。
REPLY (7) A server sends a Reply message containing
assigned addresses and configuration parameters
in response to a Solicit, Request, Renew,
Rebind message received from a client. A
server sends a Reply message containing
configuration parameters in response to an
Information-request message. A server sends a
Reply message in response to a Confirm message
confirming or denying that the addresses
assigned to the client are appropriate to the
link to which the client is connected. A
server sends a Reply message to acknowledge
receipt of a Release or Decline message.
応答(7) サーバがクライアントから受け取った、要請、要求、
更新、再結合メッセージに応えて、割り当てられた
アドレスと設定パラメータを含む応答メッセージを
送信します。サーバが情報要求メッセージに応えて、
設定パラメータを含む応答メッセージを送ります。
サーバが確証メッセージに応えて、クライアントが
接続されているリンクにクライアントに割り当てら
れたアドレスが適切であるかにより、確認か否定の
応答メッセージを送ります。サーバが解放あるいは
辞退メッセージの受領を確認する応答メッセージを
送ります。
RELEASE (8) A client sends a Release message to the server
that assigned addresses to the client to
indicate that the client will no longer use one
or more of the assigned addresses.
開放(8) クライアントが、クライアントに割り当てられたア
ドレスを使わないことを示すために、アドレスをク
ライアントに割り当てたサーバに、解放メッセージ
を送ります。
DECLINE (9) A client sends a Decline message to a server to
indicate that the client has determined that
one or more addresses assigned by the server
are already in use on the link to which the
client is connected.
辞退(9) サーバがクライアントに割り当てたアドレスに対し、
クライアントが接続されているリンクの上にすでに
使用中であると決定したことを示すために、クライ
アントがサーバに辞退メッセージを送ります。
RECONFIGURE (10) A server sends a Reconfigure message to a
client to inform the client that the server has
new or updated configuration parameters, and
that the client is to initiate a Renew/Reply
or Information-request/Reply transaction with
the server in order to receive the updated
information.
再設定(10) サーバが新しいかあるいは更新された設定パラメー
タを持ち、そしてクライアントが更新情報を受け取
るためにサーバに更新／応答あるいは情報要求／応
答処理を始めるということを知らせるため、サーバ
がクライアントに再設定メッセージを送ります。
INFORMATION-REQUEST (11) A client sends an Information-request
message to a server to request configuration
parameters without the assignment of any IP
addresses to the client.
情報要求(11) クライアントが、クライアントへのＩＰアドレスの
割当てなしで設定パラメータを求めるため、サーバ
への情報要求メッセージを送ります。
RELAY-FORW (12) A relay agent sends a Relay-forward message
to relay messages to servers, either directly
or through another relay agent. The received
message, either a client message or a
Relay-forward message from another relay
agent, is encapsulated in an option in the
Relay-forward message.
リレー転送(12) リレーエージェントが、直接あるいは他のリレーエー
ジェントを通して、サーバにメッセージを中継する
リレー転送メッセージを送ります。受信メッセージ、
クライアントメッセージあるいは他のリレーのエー
ジェントからのリレー転送メッセージ、はリレー転
送メッセージにカプセル化されます。
RELAY-REPL (13) A server sends a Relay-reply message to a relay
agent containing a message that the relay
agent delivers to a client. The Relay-reply
message may be relayed by other relay agents
for delivery to the destination relay agent.
リレー応答(13) リレーエージェントがクライアントに配達するメッ
セージを含むリレー応答メッセージを、サーバがの
エージェントへ送ります。リレー応答メッセージは
宛先リレーエージェントに配達のために他のリレー
エージェントに中継されるかもしれません。
The server encapsulates the client message as
an option in the Relay-reply message, which the
relay agent extracts and relays to the client.
サーバはリレー応答メッセージのオプションにクラ
イアントメッセージをカプセル化し、そしてそれを
リレーのエージェントが抜き出して、クライアント
に伝えます。
5.4. Status Codes
5.4. 状態コード
DHCPv6 uses status codes to communicate the success or failure of
operations requested in messages from clients and servers, and to
provide additional information about the specific cause of the
failure of a message. The specific status codes are defined in
section 24.4.
ＤＨＣＰｖ６がクライアントやサーバからのメッセージで求められたオペレー
ションの成功あるいは失敗を伝達して、そしてメッセージの失敗の特定の原
因についての追加の情報を供給するために状態コードを使います。特定の状
態コードは２４.４章で定義されます。
5.5. Transmission and Retransmission Parameters
5.5. 伝達と再送パラメータ
This section presents a table of values used to describe the message
transmission behavior of clients and servers.
この章はクライアントとサーバのメッセージ伝達行動を記述するために使わ
れた値表を示します。
Parameter Default Description
-------------------------------------
SOL_MAX_DELAY 1 sec Max delay of first Solicit
SOL_TIMEOUT 1 sec Initial Solicit timeout
SOL_MAX_RT 120 secs Max Solicit timeout value
REQ_TIMEOUT 1 sec Initial Request timeout
REQ_MAX_RT 30 secs Max Request timeout value
REQ_MAX_RC 10 Max Request retry attempts
CNF_MAX_DELAY 1 sec Max delay of first Confirm
CNF_TIMEOUT 1 sec Initial Confirm timeout
CNF_MAX_RT 4 secs Max Confirm timeout
CNF_MAX_RD 10 secs Max Confirm duration
REN_TIMEOUT 10 secs Initial Renew timeout
REN_MAX_RT 600 secs Max Renew timeout value
REB_TIMEOUT 10 secs Initial Rebind timeout
REB_MAX_RT 600 secs Max Rebind timeout value
INF_MAX_DELAY 1 sec Max delay of first Information-request
INF_TIMEOUT 1 sec Initial Information-request timeout
INF_MAX_RT 120 secs Max Information-request timeout value
REL_TIMEOUT 1 sec Initial Release timeout
REL_MAX_RC 5 MAX Release attempts
DEC_TIMEOUT 1 sec Initial Decline timeout
DEC_MAX_RC 5 Max Decline attempts
REC_TIMEOUT 2 secs Initial Reconfigure timeout
REC_MAX_RC 8 Max Reconfigure attempts
HOP_COUNT_LIMIT 32 Max hop count in a Relay-forward message
5.6 Representation of time values and "Infinity" as a time value
5.6 時刻値と時刻値としての「無限」の表現
All time values for lifetimes, T1 and T2 are unsigned integers. The
value 0xffffffff is taken to mean "infinity" when used as a lifetime
(as in RFC2461 [17]) or a value for T1 or T2.
寿命のすべての時刻値、Ｔ１とＴ２は符号なし整数です。値0xffffffffは寿
命やＴ１やＴ２の値で使用する場合は「無限」を意味します（ＲＦＣ２４６
１[17]のように）。
6. Client/Server Message Formats
6. クライアント／サーバメッセージフォーマット
All DHCP messages sent between clients and servers share an identical
fixed format header and a variable format area for options.
クライアントとサーバ間のすべてのＤＨＣＰメッセージは、同一の固定フォー
マットヘッダとオプションのための可変的フォーマットエリアを共有します。
All values in the message header and in options are in network byte
order.
すべてのメッセージヘッダとオプションの値はネットワークバイト順です。
Options are stored serially in the options field, with no padding
between the options. Options are byte-aligned but are not aligned in
any other way such as on 2 or 4 byte boundaries.
オプションは、オプションの間に間隔を空けずに、連続的にオプションフィー
ルドに設定されます。オプションはバイト整列ですが、２バイトや４バイト
などの他の境界に整列をしません。
The following diagram illustrates the format of DHCP messages sent
between clients and servers:
次の図はクライアントとサーバ間で送るメッセージのＤＨＣＰフォーマット
を例示します：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | transaction-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. options .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type Identifies the DHCP message type; the
available message types are listed in
section 5.3.
ＤＨＣＰメッセージタイプを識別します、利用可
能なメッセージタイプは５.３章でリストアップさ
れます。
transaction-id The transaction ID for this message exchange.
このメッセージ交換のための処理識別子。
options Options carried in this message; options are
described in section 22.
このメッセージで運ばれるオプション；オプショ
ンが２２章で記述されます。
7. Relay Agent/Server Message Formats
7. リレーエージェント／サーバーメッセージフォーマット
Relay agents exchange messages with servers to relay messages between
clients and servers that are not connected to the same link.
クライアントと同じリンクに接続していないサーバ間のメッセージをリレー
エージェントが中継メッセージをサーバと交換します。
All values in the message header and in options are in network byte
order.
すべてのメッセージヘッダとオプションの値はネットワークバイト順です。
Options are stored serially in the options field, with no padding
between the options. Options are byte-aligned but are not aligned in
any other way such as on 2 or 4 byte boundaries.
オプションは、オプションの間に間隔を空けずに、連続的にオプションフィー
ルドに設定されます。オプションはバイト整列ですが、２バイトや４バイト
などの他の境界に整列をしません。
There are two relay agent messages, which share the following format:
次のフォーマットを共有する２つのリレーエージェントメッセージがあります：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | hop-count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| link-address |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| peer-address |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. .
. options (variable number and length) .... .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following sections describe the use of the Relay Agent message
header.
次の章はリレーエージェントメッセージヘッダの使用を記述します。
7.1. Relay-forward Message
7.1. リレー転送メッセージ
The following table defines the use of message fields in a Relay-
forward message.
次の表はリレー転送メッセージのメッセージフィールドの使用を定義します。
msg-type RELAY-FORW
RELAY-FORW
hop-count Number of relay agents that have relayed this
message.
このメッセージを中継したリレーエージェントの数。
link-address A global or site-local address that will be used by
the server to identify the link on which the client
is located.
クライアントが位置しているリンクを識別するためにサー
バが使われるであろうグローバルかサイトローカルなア
ドレス。
peer-address The address of the client or relay agent from which
the message to be relayed was received.
中継されるメッセージを受信したクライアントかリレー
エージェントのアドレス。
options MUST include a "Relay Message option" (see
section 22.10); MAY include other options added by
the relay agent.
「リレーメッセージオプション」を含みまなければなり
ません(MUST)（２２.１０章参照）；リレーエージェント
によって加えられた他のオプションを含むかもしれませ
ん(MAY)。
7.2. Relay-reply Message
7.2. リレー応答メッセージ
The following table defines the use of message fields in a
Relay-reply message.
次の表はリレー応答メッセージのメッセージフィールドの使用を定義します。
msg-type RELAY-REPL
RELAY-REPL
hop-count Copied from the Relay-forward message
リレー転送メッセージから写し。
link-address Copied from the Relay-forward message
リレー転送メッセージから写し。
peer-address Copied from the Relay-forward message
リレー転送メッセージから写し。
options MUST include a "Relay Message option"; see
section 22.10; MAY include other options
「リレーメッセージオプション」を含みまなければなり
ません(MUST)（２２.１０章参照）；リレーエージェント
によって加えられた他のオプションを含むかもしれませ
ん(MAY)。
8. Representation and Use of Domain Names
8. ドメイン名の表現と使用
So that domain names may be encoded uniformly, a domain name or a
list of domain names is encoded using the technique described in
section 3.1 of RFC 1035 [10]. A domain name, or list of domain
names, in DHCP MUST NOT be stored in compressed form, as described in
section 4.1.4 of RFC 1035.
ドメイン名が一様にコード化されるように、ドメイン名あるいはドメイン名
のリストがＲＦＣ１０３５[10]の３.１章で記述されたテクニックを使って
コード化されます。ドメイン名あるいはＤＨＣＰでのドメイン名のリストが、
ＲＦＣ１０３５ の４.１.４章で記述されるように、圧縮された形式でしまっ
てはなりません(MUST NOT)。
9. DHCP Unique Identifier (DUID)
9. ＤＨＣＰユニーク識別子（ＤＵＩＤ）
Each DHCP client and server has a DUID. DHCP servers use DUIDs to
identify clients for the selection of configuration parameters and in
the association of IAs with clients. DHCP clients use DUIDs to
identify a server in messages where a server needs to be identified.
See sections 22.2 and 22.3 for the representation of a DUID in a DHCP
message.
各ＤＨＣＰクライアントとサーバがＤＵＩＤを持っています。ＤＨＣＰサー
バが設定パラメータの選択のためとクライアントのＩＡの連携のために、ク
ライアントを識別するＤＵＩＤを使います。ＤＨＣＰクライアントは、サー
バが識別される必要があるメッセージでサーバを識別するためにＤＵＩＤを
使います。ＤＨＣＰメッセージのＤＵＩＤ表現は２２.２章と２２.３章を見
てください。
Clients and servers MUST treat DUIDs as opaque values and MUST only
compare DUIDs for equality. Clients and servers MUST NOT in any
other way interpret DUIDs. Clients and servers MUST NOT restrict
DUIDs to the types defined in this document, as additional DUID types
may be defined in the future.
クライアントとサーバがＤＵＩＤを不透明な値として取り扱わなくてはなら
なくて、そしてただ同一性のためにＤＵＩＤを比較するだけでなくてはなり
ません(MUST)。クライアントとサーバが他の方法でＤＵＩＤを解釈してはな
りません(MUST NOT)。追加のＤＵＩＤタイプが将来定義されるかもしれない
から、クライアントとサーバがＤＵＩＤをこの文書で定義されたタイプに制
限してはなりません。
The DUID is carried in an option because it may be variable length
and because it is not required in all DHCP messages. The DUID is
designed to be unique across all DHCP clients and servers, and stable
for any specific client or server - that is, the DUID used by a
client or server SHOULD NOT change over time if at all possible; for
example, a device's DUID should not change as a result of a change in
the device's network hardware.
ＤＵＩＤは可変長かもしれず、また、すべてのＤＨＣＰメッセージで必要と
はされないので、オプションで運ばれます。ＤＵＩＤは全てのＤＨＣＰクラ
イアントとサーバで一意で、特定のクライアントとサーバで安定するよう意
図されます−すなわち、クライアントやサーバが使うＤＵＩＤは可能な限り
変更するべきではありません(SHOULD NOT)；例えば、装置のＤＵＩＤは装置
のネットワークハードウェアの変更の結果として変化するべきではありませ
ん。
The motivation for having more than one type of DUID is that the DUID
must be globally unique, and must also be easy to generate. The sort
of globally-unique identifier that is easy to generate for any given
device can differ quite widely. Also, some devices may not contain
any persistent storage. Retaining a generated DUID in such a device
is not possible, so the DUID scheme must accommodate such devices.
ＤＵＩＤに複数のタイプを動機はＤＵＩＤが世界的規模でユニークに違いな
く、そして同じく生成することが容易であるに違いないということです。所
定の装置で生成することが容易である種類のグローバルユニーク識別子は非
常に広く異なります。同じく、ある装置が不発揮性記憶装置を含んでいない
かもしれません。このような装置で生成されたＤＵＩＤを維持することは可
能ではありません、それでＤＵＩＤ案はこのような装置を収容しなくてはな
りません。
9.1. DUID Contents
9.1. ＤＵＩＤ中身
A DUID consists of a two-octet type code represented in network byte
order, followed by a variable number of octets that make up the
actual identifier. A DUID can be no more than 128 octets long (not
including the type code). The following types are currently defined:
ＤＵＩＤがネットワークバイト順の２オクテットの種別コードと、その後に
可変長オクテットの実際の識別子から成り立ちます。ＤＵＩＤは（種別コー
ドを含めて）１２８オクテットより大きくあり得ません。次の種別が現在定
義されます：
1 Link-layer address plus time
リンク層アドレスと時刻
2 Vendor-assigned unique ID based on Enterprise Number
企業番号に基づいてベンダが割り当てられたユニークな識別子
3 Link-layer address
リンク層アドレス
Formats for the variable field of the DUID for each of the above
types are shown below.
上記の種別のそれぞれのＤＵＩＤの可変フィールドのフォーマットが下記の
通りです。
9.2. DUID Based on Link-layer Address Plus Time [DUID-LLT]
9.2. リンク層アドレスと時刻プラス時間に基づいたＤＵＩＤ[DUID-LLT]
This type of DUID consists of a two octet type field containing the
value 1, a two octet hardware type code, four octets containing a
time value, followed by link-layer address of any one network
interface that is connected to the DHCP device at the time that the
DUID is generated. The time value is the time that the DUID is
generated represented in seconds since midnight (UTC), January 1,
2000, modulo 2^32. The hardware type MUST be a valid hardware type
assigned by the IANA as described in RFC 826 [14]. Both the time and
the hardware type are stored in network byte order. The link-layer
address is stored in canonical form, as described in RFC 2464 [2].
この種類のＤＵＩＤは、値１を含む２オクテットの種別フィールドと、２オ
クテットハードウェアコードと、４オクテット時間値と、それに続くＤＵＩ
Ｄが生成されたときにＤＨＣＰ装置に接続したインターフェースのリンク層
アドレスから成り立ちます。時刻値はＤＵＩＤが生成された時刻で、２００
０年１月１日の真夜中（ＵＴＣ）からの秒数を２＾３２で割った余りで表現
します。ハードウェアタイプは、ＲＦＣ８２６[14]で記述されるように、Ｉ
ＡＮＡによって割り当てられる正当なハードウェアタイプに違いありません。
時刻とハードウェアタイプの両方がネットワークバイト順に保存されます。
リンク層アドレスは、ＲＦＣ２４６４[2]で記述されるように、規準形式で設
定されます。
The following diagram illustrates the format of a DUID-LLT:
次の図はＤＵＩＤ−ＬＴＴのフォーマットを例示します：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | hardware type (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. link-layer address (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The choice of network interface can be completely arbitrary, as long
as that interface provides a globally unique link-layer address for
the link type, and the same DUID-LLT SHOULD be used in configuring
all network interfaces connected to the device, regardless of which
interface's link-layer address was used to generate the DUID-LLT.
インタフェースがそのリンク種別でグローバルにユニークなリンクレイヤア
ドレスを提供する限りネットワークインタフェースの選択は完全に任意で、
そしてどのインタフェースのリンクレイヤアドレスがＤＵＩＤ−ＬＴＴを生
成するため使われたかに関わらず、同じＤＵＩＤ−ＬＴＴがその装置に接続
した全てのネットワークインタフェースの構成の設定で使われるべきです。
Clients and servers using this type of DUID MUST store the DUID-LLT
in stable storage, and MUST continue to use this DUID-LLT even if the
network interface used to generate the DUID-LLT is removed. Clients
and servers that do not have any stable storage MUST NOT use this
type of DUID.
この種類のＤＵＩＤを使っているクライアントとサーバがＤＵＩＤ−ＬＴＴ
を安定した記憶装置に記憶しなければならず(MUST)、そして、たとえＤＵＩ
Ｄ−ＬＴＴを生み出すために使われたネットワークインタフェースが取り除
かれたとしても、このＤＵＩＤ−ＬＴＴを使い続けなくてはなりません
(MUST)。安定した記憶装置を持っていないクライアントとサーバがこの種類
のＤＵＩＤを使ってはなりません(MUST NOT)。
Clients and servers that use this DUID SHOULD attempt to configure
the time prior to generating the DUID, if that is possible, and MUST
use some sort of time source (for example, a real-time clock) in
generating the DUID, even if that time source could not be configured
prior to generating the DUID. The use of a time source makes it
unlikely that two identical DUID-LLTs will be generated if the
network interface is removed from the client and another client then
uses the same network interface to generate a DUID-LLT. A collision
between two DUID-LLTs is very unlikely even if the clocks have not
been configured prior to generating the DUID.
このＤＵＩＤを使うクライアントとサーバが、もし可能なら、ＤＵＩＤを生
成する前に時間の設定を試みるべきで(SHOULD)、ＤＵＩＤを生成する時に、
例え時刻情報源がＤＵＩＤを生成前に設定できなくても、なんらかの時刻情
報源（例えばリアルタイム時計）を使わなければなりません(MUST)。時間情
報源を使事で、もしネットワークインターフェースがクライアントから取り
除かれ、他のクライアントがこのネットワークインターフェースを使いＤＵ
ＩＤ−ＬＬＴを生成する場合に、２つの同一のＤＵＩＤ−ＬＴＴが生成され
る事がまずないようにします。２つのＤＵＩＤ−ＬＬＴの衝突は、たとえ時
計がＤＵＩＤ生成前に設定されていなくても、非常にありそうもないです。
This method of DUID generation is recommended for all general purpose
computing devices such as desktop computers and laptop computers, and
also for devices such as printers, routers, and so on, that contain
some form of writable non-volatile storage.
このＤＵＩＤ生成方法はすべてのデスクトップコンピュータとラップトップ
コンピュータのような汎用の計算装置と、そして同じくプリンタやルータな
ど何らかの書込み可能な不発揮記憶を含む装置で勧められます。
Despite our best efforts, it is possible that this algorithm for
generating a DUID could result in a client identifier collision. A
DHCP client that generates a DUID-LLT using this mechanism MUST
provide an administrative interface that replaces the existing DUID
with a newly-generated DUID-LLT.
我々の最善の努力にもかかわらず、このＤＵＩＤを生成するアルゴリズムが
クライアント識別子の衝突をもたらすことは可能です。このメカニズムを使っ
ているＤＵＩＤ−ＬＬＴを生成するＤＨＣＰクライアントが新たに生成され
たＤＵＩＤ−ＬＬＴで既存のＤＵＩＤを置き換える管理インタフェースを提
供しなくてはなりません(MUST)。
9.3. DUID Assigned by Vendor Based on Enterprise Number [DUID-EN]
9.3. 企業番号に基づいてベンダによって割り当てられるＤＵＩＤ[DUID-EN]
This form of DUID is assigned by the vendor to the device. It
consists of the vendor's registered Private Enterprise Number as
maintained by IANA [6] followed by a unique identifier assigned by
the vendor. The following diagram summarizes the structure of a
DUID-EN:
このＤＵＩＤの形式は装置にベンダによって割り当てられます。これはＩＡ
ＮＡ[6]によって維持されるベンダの登録された私企業番号と、それに続くベ
ンダによって割り当てられたユニークな識別子によって成り立ちます。次の
図はＤＵＩＤ−ＥＮの構造を要約します：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number (contd) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. identifier .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The source of the identifier is left up to the vendor defining it,
but each identifier part of each DUID-EN MUST be unique to the device
that is using it, and MUST be assigned to the device at the time it
is manufactured and stored in some form of non-volatile storage. The
generated DUID SHOULD be recorded in non-erasable storage. The
enterprise-number is the vendor's registered Private Enterprise
Number as maintained by IANA [6]. The enterprise-number is stored as
an unsigned 32 bit number.
識別子の情報源はこれを定義しているベンダに任せられますが、それぞれの
ＤＵＩＤ−ＥＮの識別子部分がそれを使っている装置に特有であるに違いな
くて(MUST)、そして製造時に装置に割り当てられて、そしてある不発揮性の
記憶場所にしまっておかれなくてはなりません(MUST)。生成されたＤＵＩＤ
は消去可能でない記憶装置に記録されるべきです(SHOULD)。企業数番号はＩ
ＡＮＡ[6]で維持されるベンダの登録された私企業番号です。企業番号は符号
なしの３２ビット番号として記憶されます。
An example DUID of this type might look like this:
例えば、この種類のＤＵＩＤが以下のように見えるかもしれません：
+---+---+---+---+---+---+---+---+
| 0 | 2 | 0 | 0 | 0 | 9| 12|192|
+---+---+---+---+---+---+---+---+
|132|221| 3 | 0 | 9 | 18|
+---+---+---+---+---+---+
This example includes the two-octet type of 2, the Enterprise Number
(9), followed by eight octets of identifier data
(0x0CC084D303000912).
この例は２オクテットの企業番号(9)とその後に続く８オクテットの識別子
データ(0x0CC084D303000912)を含みます。
9.4. DUID Based on Link-layer Address [DUID-LL]
9.4. リンク層アドレスに基づいたＤＵＩＤ[DUID-LL]
This type of DUID consists of two octets containing the DUID type 3,
a two octet network hardware type code, followed by the link-layer
address of any one network interface that is permanently connected to
the client or server device. For example, a host that has a network
interface implemented in a chip that is unlikely to be removed and
used elsewhere could use a DUID-LL. The hardware type MUST be a
valid hardware type assigned by the IANA, as described in RFC 826
[14]. The hardware type is stored in network byte order. The
link-layer address is stored in canonical form, as described in RFC
2464 [2]. The following diagram illustrates the format of a DUID-LL:
この種類のＤＵＩＤは、ＤＵＩＤ種別３を含む２オクテットと、２オクテッ
トネットワークハードウェア種別コードと、そしてその後に永久にクライア
ントあるいはサーバ装置に接続しているネットワークインタフェースの１つ
のリンクレイヤアドレスから成り立ちます。例えば、ネットワークインタ
フェースが、取り外して他で使えないようなチップに実装されるホストが、
ＤＵＩＤ−ＬＬを使うことができます。ハードウェアタイプは、ＲＦＣ８２
６[14]で記述されるように、ＩＡＮＡによって割り当てられる正当なハード
ウェアタイプであるに違いありません(MUST)。ハードウェアタイプはネット
ワークバイト順に設定されます。リンク層アドレスは、ＲＦＣ２４６４[2]で
記述されるように、規準形式に設定されます。次の図はＤＵＩＤ−ＬＬの
フォーマットを例示します：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | hardware type (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. link-layer address (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The choice of network interface can be completely arbitrary, as long
as that interface provides a unique link-layer address and is
permanently attached to the device on which the DUID-LL is being
generated. The same DUID-LL SHOULD be used in configuring all
network interfaces connected to the device, regardless of which
interface's link-layer address was used to generate the DUID.
インタフェースがユニークなリンクレイヤアドレスを供給する限りネットワー
クインタフェースの選択は完全に任意で、そして永久にＤＵＩＤ−ＬＬが生
成される装置に置かれます。どのインタフェースのリンクレイヤアドレスが
ＤＵＩＤを作るために使われたかに関わらず、すべてのネットワークインタ
フェースの構成の設定で同じＤＵＩＤ−ＬＬが使われるべきです(SHOULD)。
DUID-LL is recommended for devices that have a permanently-connected
network interface with a link-layer address, and do not have
nonvolatile, writable stable storage. DUID-LL MUST NOT be used by
DHCP clients or servers that cannot tell whether or not a network
interface is permanently attached to the device on which the DHCP
client is running.
ＤＵＩＤ−ＬＬは、リンクレイヤアドレスで永久に接続しているネットワー
クインタフェースを持ち、そして不発揮性の書き込み可能な安定した記憶装
置を持たない装置に勧められます。ＤＵＩＤ−ＬＬはネットワークインタ
フェースが永久にＤＨＣＰクライアントがある装置に置かれるかどうかを言
うことができないＤＨＣＰクライアントやサーバによって使われてはなりま
せん(MUST NOT)。
10. Identity Association
10. 識別子集団
An "identity-association" (IA) is a construct through which a server
and a client can identify, group, and manage a set of related IPv6
addresses. Each IA consists of an IAID and associated configuration
information.
「識別子集団」（ＩＡ）がサーバとクライアントが関連したＩＰｖ６アドレ
ス群を識別し、まとめて、管理ができる概念です。各ＩＡがＩＡＩＤから成
り立ち、そして設定情報を関連づけます。
A client must associate at least one distinct IA with each of its
network interfaces for which it is to request the assignment of IPv6
addresses from a DHCP server. The client uses the IAs assigned to an
interface to obtain configuration information from a server for that
interface. Each IA must be associated with exactly one interface.
ＤＨＣＰサーバからＩＰｖ６アドレスの割当てを求めるネットワークインタ
フェースのそれぞれに、クライアントは少なくとも１つの異なるＩＡを関連
付けなければなりません。クライアントはサーバからインタフェースの設定
情報を得るために、そのインタフェースに割り当てられたＩＡを使います。
それぞれのＩＡが正確に１つのインタフェースと結び付けられなくてはなり
ません。
The IAID uniquely identifies the IA and must be chosen to be unique
among the IAIDs on the client. The IAID is chosen by the client.
For any given use of an IA by the client, the IAID for that IA MUST
be consistent across restarts of the DHCP client. The client may
maintain consistency either by storing the IAID in non-volatile
storage or by using an algorithm that will consistently produce the
same IAID as long as the configuration of the client has not changed.
There may be no way for a client to maintain consistency of the IAIDs
if it does not have non-volatile storage and the client's hardware
configuration changes.
ＩＡＩＤはユニークにＩＡを識別し、そしてクライアント上のＩＡＩＤ間で
ユニークであるように選ばれなくてはなりません。ＩＡＩＤはクライアント
によって選択されます。クライアントによって使用中のＩＡに対し、ＩＡの
ＩＡＩＤがＤＨＣＰクライアントの再起動後も整合していなければなりませ
ん(MUST)。クライアントはＩＡＩＤを不発揮性の記憶場所に記憶するか、ク
ライアントの設定が変化しない限り、一貫して同じＩＡＩＤを作り出すアル
ゴリズムを使うことで一貫性を維持してもよいです。クライアントがもし不
発揮性の記憶場所を持たなく、そしてクライアントのハードウェア設定が変
化する場合、ＩＡＩＤの一貫性を維持する方法がないかもしれません。
The configuration information in an IA consists of one or more IPv6
addresses along with the times T1 and T2 for the IA. See section
22.4 for the representation of an IA in a DHCP message.
ＩＡの設定情報は１つ以上のＩＰｖ６アドレスと、ＩＡの時間Ｔ１とＴ２か
ら成り立ちます。ＤＨＣＰメッセージでのＩＡの表現は２２.４章を見てく
ださい。
Each address in an IA has a preferred lifetime and a valid lifetime,
as defined in RFC 2462 [17]. The lifetimes are transmitted from the
DHCP server to the client in the IA option. The lifetimes apply to
the use of IPv6 addresses, as described in section 5.5.4 of RFC 2462.
各ＩＡのアドレスが、ＲＦＣ２４６２[17]で定義されるように、望ましい寿
命と正式な寿命を持っています。寿命はＩＡオプションでＤＨＣＰサーバか
らクライアントに伝達されます。寿命は、ＲＦＣ２４６２の５.５.４章で記
述されるように、ＩＰｖ６アドレスの使用に当てはまります。
11. Selecting Addresses for Assignment to an IA
11. ＩＡに割当てるアドレスの選択
A server selects addresses to be assigned to an IA according to the
address assignment policies determined by the server administrator
and the specific information the server determines about the client
from some combination of the following sources:
サーバがサーバ管理者が決定したアドレス割当てポリシーに従って、次の情
報の組合わせから決定したクライアントのＩＡに割当てるアドレスと特定の
情報を選択します：
- The link to which the client is attached. The server determines
the link as follows:
クライアントが接続しているリンク。サーバは次のようにリンクを決定
します：
* If the server receives the message directly from the client and
the source address in the IP datagram in which the message was
received is a link-local address, then the client is on the
same link to which the interface over which the message was
received is attached.
もしサーバが直接クライアントからメッセージを受け取り、そして受
信したメッセージのＩＰデータグラムのソースアドレスがリンクロー
カルアドレスであるなら、クライアントはメッセージを受け取ったイ
ンタフェースが接続しているのと同じリンクの上にあります。
* If the server receives the message from a forwarding relay
agent, then the client is on the same link as the one to which
the interface, identified by the link-address field in the
message from the relay agent, is attached.
もしサーバが転送リレーエージェントからのメッセージを受け取るな
ら、クライアントはリレーエージェントからのメッセージのリンクア
ドレスフィールドで識別されたインタフェースが接続しているのと同
じリンクの上にあります。
* If the server receives the message directly from the client and
the source address in the IP datagram in which the message was
received is not a link-local address, then the client is on the
link identified by the source address in the IP datagram (note
that this situation can occur only if the server has enabled
the use of unicast message delivery by the client and the
client has sent a message for which unicast delivery is
allowed).
もしサーバが直接クライアントからメッセージを受け取り、そして受
信メッセージのＩＰデータグラムのソースアドレスがリンクローカル
アドレスではないなら、クライアントはＩＰデータグラムでソースア
ドレスによって識別されえるリンクの上にあります（サーバがクライ
アントにユニキャストメッセージ配達の使用を許し、そしてクライア
ントがユニキャスト配達が許されるメッセージを送った場合に限り、
この状態が存在することができることに注意してください）。
- The DUID supplied by the client.
クライアントから供給されるＤＵＩＤ
- Other information in options supplied by the client.
任意でクライアントから供給される他の情報
- Other information in options supplied by the relay agent.
任意でリレーエージェントから供給される他の情報
Any address assigned by a server that is based on an EUI-64
identifier MUST include an interface identifier with the "u"
(universal/local) and "g" (individual/group) bits of the interface
identifier set appropriately, as indicated in section 2.5.1 of RFC
2373 [5].
サーバによって割り当てられたＥＵＩ６４識別子に基づくアドレスは、イン
タフェース識別子の「ｕ」（ユニバーサル／ローカル）ビットと「ｇ」（個
人／グループ）ビットが、ＲＦＣ２３７３[5]の２.５.１章で示されるように、
適切に設定しなければなりません(MUST)。
A server MUST NOT assign an address that is otherwise reserved for
some other purpose. For example, a server MUST NOT assign reserved
anycast addresses, as defined in RFC 2526, from any subnet.
サーバが何か他の目的で確保されるアドレスを割り当ててはなりません(MUST
NOT)。例えば、サーバがサブネットで、ＲＦＣ２５２６で定義される予約の
エニキャストアドレスを割り当ててはなりません(MUST NOT)。
12. Management of Temporary Addresses
12. 一時的なアドレス管理
A client may request the assignment of temporary addresses (see RFC
3041 [12] for the definition of temporary addresses). DHCPv6
handling of address assignment is no different for temporary
addresses. DHCPv6 says nothing about details of temporary addresses
like lifetimes, how clients use temporary addresses, rules for
generating successive temporary addresses, etc.
クライアントが一時的なアドレスの割当てを求めるかもしれません（一時的
なアドレスの定義はＲＦＣ３０４１[12]参照）。ＤＨＣＰｖ６での一時的ア
ドレスのアドレス割当の扱いは異なりません。ＤＨＣＰｖ６が寿命や、クラ
イアントが一時的なアドレスを使う方法や、連続した一時的なアドレスを生
成する規則など、一時的アドレスの詳細について何も言いません。
Clients ask for temporary addresses and servers assign them.
Temporary addresses are carried in the Identity Association for
Temporary Addresses (IA_TA) option (see section 22.5). Each IA_TA
option contains at most one temporary address for each of the
prefixes on the link to which the client is attached.
クライアントが一時的アドレスを求め、そしてサーバが割り当てます。一時
的なアドレスが一時的アドレスのために識別子集団（ＩＡ＿ＴＡ）オプショ
ンで運ばれます（２２.５章参照）。それぞれのＩＡ＿ＴＡオプションは、ク
ライアントが接続するリンク上のプレフィックスのそれぞれについて、多く
とも１つの一時的アドレスを含んでいます。
The IAID number space for the IA_TA option IAID number space is
separate from the IA_NA option IAID number space.
ＩＡ＿ＴＡオプションＩＡＩＤ番号空間のＩＡＩＤ番号空間はＵＡ＿ＮＡオ
プションＩＡＩＤ番号空間から独立しています。
The server MAY update the DNS for a temporary address, as described
in section 4 of RFC 3041.
サーバは、ＲＦＣ３０４１の４章で記述されるように、一時的アドレスのＤ
ＮＳを更新してもよいです(MAY)。
13. Transmission of Messages by a Client
13. クライアントによるメッセージの伝達
Unless otherwise specified in this document, or in a document that
describes how IPv6 is carried over a specific type of link (for link
types that do not support multicast), a client sends DHCP messages to
the All_DHCP_Relay_Agents_and_Servers.
この文書であるいは（マルチキャストをサポートしない）特定の種類のリン
ク上でどのようにＩＰｖ６が運ばれるか記述する文書で指定されない限り、
クライアントが全ＤＨＣＰリレーエージェントアンドサーバにＤＨＣＰメッ
セージを送ります。
A client uses multicast to reach all servers or an individual server.
An individual server is indicated by specifying that server's DUID in
a Server Identifier option (see section 22.3) in the client's message
(all servers will receive this message but only the indicated server
will respond). All servers are indicated by not supplying this
option.
クライアントがすべてのサーバあるいは個別のサーバと連絡を取るためにマ
ルチキャストを使います。個別のサーバはクライアントのメッセージのでサー
バ識別子オプション（２２.３章参照）でそのサーバのＤＵＩＤを指定するこ
とによって示されます（全サーバはこのメッセージを受け取るであろうが、
示されたサーバだけが返答するであろう）。全サーバはこのオプションを供
給しないことによって示されます。
A client may send some messages directly to a server using unicast,
as described in section 22.12.
クライアントが直接、２２.１２章で記述されるように、ユニキャストを使っ
てサーバにあるメッセージを送ってもよいです。
14. Reliability of Client Initiated Message Exchanges
14. クライアントによって始められたメッセージ交換の信頼性
DHCP clients are responsible for reliable delivery of messages in the
client-initiated message exchanges described in sections 17 and 18.
If a DHCP client fails to receive an expected response from a server,
the client must retransmit its message. This section describes the
retransmission strategy to be used by clients in client-initiated
message exchanges.
ＤＨＣＰクライアントは１７章と１８章で記述されたクライアントによって
始められたメッセージ交換でメッセージの信頼性が高い配達に関して責任が
あります。もしＤＨＣＰクライアントがサーバから期待された回答を受け取
り損ねるなら、クライアントはそのメッセージを再び送らなくてはなりませ
ん。この章はクライアントによって始められたメッセージ交換でクライアン
トによって使われる再送戦略を記述します。
Note that the procedure described in this section is slightly
modified when used with the Solicit message. The modified procedure
is described in section 17.1.2.
この章で記述した手順は、要請メッセージで使われる時、わずかに修正され
ます。修正された手順は１７.１.２章で記述されます。
The client begins the message exchange by transmitting a message to
the server. The message exchange terminates when either the client
successfully receives the appropriate response or responses from a
server or servers, or when the message exchange is considered to have
failed according to the retransmission mechanism described below.
クライアントはサーバへのメッセージを伝達することでメッセージ交換を始
めます。クライアントが成功裏にサーバから適切な回答を受け取るか、メッ
セージ交換が下記の再送メカニズムによって失敗したと考えられる時に、メッ
セージ交換は終了します。
The client retransmission behavior is controlled and described by the
following variables:
クライアント再送行動は以下の変数によって以下に記述されるように制御されます：
RT Retransmission timeout
再送タイムアウト
IRT Initial retransmission time
最初の再送時間
MRC Maximum retransmission count
最大の再送カウント
MRT Maximum retransmission time
最大再送時時間
MRD Maximum retransmission duration
最大再送持続時間
RAND Randomization factor
ランダム化要因
With each message transmission or retransmission, the client sets RT
according to the rules given below. If RT expires before the message
exchange terminates, the client recomputes RT and retransmits the
message.
それぞれのメッセージ伝達あるいは再送で、クライアントは下記の規則でRT
を設定します。もしRTがメッセージ交換が終わる前に期限切れになるなら、
クライアントはRTを再計算して、そしてメッセージを再び送ります。
Each of the computations of a new RT include a randomization factor
(RAND), which is a random number chosen with a uniform distribution
between -0.1 and +0.1. The randomization factor is included to
minimize synchronization of messages transmitted by DHCP clients.
The algorithm for choosing a random number does not need to be
cryptographically sound. The algorithm SHOULD produce a different
sequence of random numbers from each invocation of the DHCP client.
各新しいRT計算は、ランダム化要因(RAND)を含み、乱数は-0.1から+0.1の間
の一様分布で選択されます。ランダム化要因はＤＨＣＰクライアントによっ
て伝達されたメッセージの同時発生を最小にするために含まれます。乱数を
選択するためのアルゴリズムは暗号的に強固である必要がありません。アル
ゴリズムはそれぞれのＤＨＣＰクライアントの実行で異なった乱数列を作り
出すべきです(SHOULD)。
RT for the first message transmission is based on IRT:
最初のメッセージ伝達のRTはＩＲＴに基づきます：
RT = IRT + RAND*IRT
RT for each subsequent message transmission is based on the previous
value of RT:
それぞれの次のメッセージ伝達のRTは前のRT値に基づいています：
RT = 2*RTprev + RAND*RTprev
MRT specifies an upper bound on the value of RT (disregarding the
randomization added by the use of RAND). If MRT has a value of 0,
there is no upper limit on the value of RT. Otherwise:
MRTは（RANDの使用によって加えられたランダム追加を無視して）RT値に上限
を指定します。もしMRTが０の値を持っているなら、RT値に上限がありません。
さもなければ：
if (RT > MRT)
RT = MRT + RAND*MRT
MRC specifies an upper bound on the number of times a client may
retransmit a message. Unless MRC is zero, the message exchange fails
once the client has transmitted the message MRC times.
MRCはクライアントがメッセージを再送してもよい回数の上限を指定します。
MRCがゼロではないなら、メッセージ交換は、クライアントがメッセージを
MRC回伝達したら失敗します。
MRD specifies an upper bound on the length of time a client may
retransmit a message. Unless MRD is zero, the message exchange fails
once MRD seconds have elapsed since the client first transmitted the
message.
MRDはクライアントがメッセージを再送してもよい時間の長さの上限を指定し
ます。MRDがゼロでないなら、メッセージ交換は、クライアントが最初にメッ
セージを伝達した時から、MRD秒経過したら失敗します。
If both MRC and MRD are non-zero, the message exchange fails whenever
either of the conditions specified in the previous two paragraphs are
met.
もし MRCとMRD両方がゼロ以外であるなら、メッセージ交換は、前の２つの段
落で明示した状態のいずれかの場合に、失敗します。
If both MRC and MRD are zero, the client continues to transmit the
message until it receives a response.
もしMRCとMRD両方がゼロであるなら、クライアントは回答を受け取るまで、
メッセージを伝達し続けます。
15. Message Validation
15. メッセージ検証
Clients and servers SHOULD discard any messages that contain options
that are not allowed to appear in the received message. For example,
an IA option is not allowed to appear in an Information-request
message. Clients and servers MAY choose to extract information from
such a message if the information is of use to the recipient.
クライアントとサーバが受信メッセージに現われることを許されないオプショ
ンを含んでいるメッセージを捨てるべきです(SHOULD)。例えば、ＩＡオプショ
ンが情報要求メッセージに現われることを許されません。クライアントとサー
バが、も情報が受信者に役立つなら、このようなメッセージから情報の抽出
をすることに決めてもよいです(MAY)。
A server MUST discard any Solicit, Confirm, Rebind or
Information-request messages it receives with a unicast destination
address.
サーバがユニキャスト宛先アドレスで受信する要請と確証と再結合と情報要
求メッセージを捨てなくてはなりません(MUST)。
Message validation based on DHCP authentication is discussed in
section 21.4.2.
ＤＨＣＰ認証に基づいたメッセージ確証が２１.４.２章で論じられます。
If a server receives a message that contains options it should not
contain (such as an Information-request message with an IA option),
is missing options that it should contain, or is otherwise not valid,
it MAY send a Reply (or Advertise as appropriate) with a Server
Identifier option, a Client Identifier option if one was included in
the message and a Status Code option with status UnSpecFail.
もしサーバが含んでいるべきでないオプションを含んでいるか（例えば、Ｉ
Ａオプションを持っている情報要求メッセージ）、含むべきオプションが欠
けているか、何か他に正しくないメッセージを受け取るなら、サーバー識別
子オプションと、メッセージにあった場合はクライアント識別子オプション
と、UnSpecFailの値の状態コードで応答（又は適切なら、広告）を送るかも
しれません(MAY)。
15.1. Use of Transaction IDs
15.1. 処理識別子の使用
The "transaction-id" field holds a value used by clients and servers
to synchronize server responses to client messages. A client SHOULD
generate a random number that cannot easily be guessed or predicted
to use as the transaction ID for each new message it sends. Note
that if a client generates easily predictable transaction
identifiers, it may become more vulnerable to certain kinds of
attacks from off-path intruders. A client MUST leave the transaction
ID unchanged in retransmissions of a message.
「処理識別子」フィールドはクライアントメッセージに対するサーバ回答を
同期させるためにクライアントとサーバによって使われる値を持ちます。ク
ライアントが送るそれぞれの新しいメッセージの処理識別子として、容易に
推測や予測ができない乱数を生成するべきです(SHOULD)。もしクライアント
が容易に予測可能な処理識別子を生成するなら、外部からの侵入者のある特
定の種類の攻撃により傷つきやすくなるかもしれないことに注意してくださ
い。クライアントがメッセージの再送で処理識別子を変化していないままに
しておかなくてはなりません(MUST)。
15.2. Solicit Message
15.2. 要請メッセージ
Clients MUST discard any received Solicit messages.
クライアントが受信した要請メッセージを捨てなくてはなりません(MUST)。
Servers MUST discard any Solicit messages that do not include a
Client Identifier option or that do include a Server Identifier
option.
サーバがクライアント識別子オプションを含まないか、サーバ識別子オプショ
ンをを含む要請メッセージを捨てなくてはなりません(MUST)。
15.3. Advertise Message
15.3. 広告メッセージ
Clients MUST discard any received Advertise messages that meet any of
the following conditions:
クライアントが次の状態のいずれかの受信広告メッセージを捨てなくてはな
りません(MUST)：
- the message does not include a Server Identifier option.
メッセージはサーバ識別子オプションを含みません。
- the message does not include a Client Identifier option.
メッセージはクライアント識別子オプションを含みません。
- the contents of the Client Identifier option does not match the
client's DUID.
クライアント識別子オプションの中身がクライアントのＤＵＩＤ一致し
ない。
- the "transaction-id" field value does not match the value the
client used in its Solicit message.
「処理識別子」フィールド値がクライアントが要請メッセージで使った
値に一致しない。
Servers and relay agents MUST discard any received Advertise
messages.
サーバとリレーエージェントが受信広告メッセージを捨てなくてはなりま
せん(MUST)。
15.4. Request Message
15.4. 要求メッセージ
Clients MUST discard any received Request messages.
クライアントが受信した要求メッセージを捨てなくてはなりません(MUST)。
Servers MUST discard any received Request message that meet any of
the following conditions:
サーバが受信する次の状態のいずれかの要求メッセージは捨てなくては
なりません(MUST)：
- the message does not include a Server Identifier option.
メッセージはサーバ識別子オプションを含みません。
- the contents of the Server Identifier option do not match the
server's DUID.
サーバ識別子オプションの中身はサーバのＤＵＩＤに合いません。
- the message does not include a Client Identifier option.
メッセージはクライアント識別子オプションを含みません。
15.5. Confirm Message
15.5. 確証メッセージ
Clients MUST discard any received Confirm messages.
クライアントが受信した確証メッセージを捨てなくてはなりません(MUST)。
Servers MUST discard any received Confirm messages that do not
include a Client Identifier option or that do include a Server
Identifier option.
サーバがクライアント識別子オプションを含まないか、あるいはサーバ識別
子オプションを含むどんな受信した確証メッセージでを捨てなくてはなりま
せん(MUST)。
15.6. Renew Message
15.6. 更新メッセージ
Clients MUST discard any received Renew messages.
クライアントが受信した更新メッセージを捨てなくてはなりません(MUST)。
Servers MUST discard any received Renew message that meets any of the
following conditions:
サーバが次の状態のいずれかの受信した更新メッセージを捨てなくてはなり
ません(MUST)：
- the message does not include a Server Identifier option.
メッセージはサーバ識別子オプションを含んでいない。
- the contents of the Server Identifier option does not match the
server's identifier.
サーバ識別子オプションの中身はサーバの識別子に一致していない。
- the message does not include a Client Identifier option.
メッセージはクライアント識別子オプションを含んでいない。
15.7. Rebind Message
15.7. 再結合メッセージ
Clients MUST discard any received Rebind messages.
クライアントが受信した再結合メッセージを捨てなくてはなりません。
Servers MUST discard any received Rebind messages that do not include
a Client Identifier option or that do include a Server Identifier
option.
サーバがクライアント識別子オプションを含まない、あるいはサーバ識別子
オプションを含まない、受信再結合メッセージを捨てなくてはなりません
(MUST)。
15.8. Decline Messages
15.8. 辞退メッセージ
Clients MUST discard any received Decline messages.
クライアントが受信した辞退メッセージを捨てなくてはなりません(MUST)。
Servers MUST discard any received Decline message that meets any of
the following conditions:
サーバが次の状態のどれかになっている受信した辞退メッセージを捨てなく
てはなりません(MUST)：
- the message does not include a Server Identifier option.
メッセージはサーバ識別子オプションを含んでいない。
- the contents of the Server Identifier option does not match the
server's identifier.
サーバ識別子オプションの中身はサーバの識別子に一致していない。
- the message does not include a Client Identifier option.
メッセージはクライアント識別子オプションを含んでいない。
15.9. Release Message
15.9. 開放メッセージ
Clients MUST discard any received Release messages.
クライアントが受信した開放メッセージを捨てなくてはなりません(MUST)。
Servers MUST discard any received Release message that meets any of
the following conditions:
サーバが次の状態のどれかになっている受信した開放メッセージを捨てなく
てはなりません(MUST)：
- the message does not include a Server Identifier option.
メッセージはサーバ識別子オプションを含んでいない。
- the contents of the Server Identifier option does not match the
server's identifier.
サーバ識別子オプションの中身はサーバの識別子に一致していない。
- the message does not include a Client Identifier option.
メッセージはクライアント識別子オプションを含んでいない。
15.10. Reply Message
15.10. 応答メッセージ
Clients MUST discard any received Reply message that meets any of the
following conditions:
サーバが次の状態のどれかになっている受信した辞退メッセージを捨てなく
てはなりません(MUST)：
- the message does not include a Server Identifier option.
メッセージはサーバ識別子オプションを含まなくてはなりません(MUST)。
- the "transaction-id" field in the message does not match the value
used in the original message.
メッセージの「処理識別子」フィールドはオリジナルのメッセージで使わ
れた値に一致しなくてはなりません(MUST)。
If the client included a Client Identifier option in the original
message, the Reply message MUST include a Client Identifier option
and the contents of the Client Identifier option MUST match the DUID
of the client; OR, if the client did not include a Client Identifier
option in the original message, the Reply message MUST NOT include a
Client Identifier option.
もしクライアントが元のメッセージにクライアント識別子オプションを含め
たなら、応答メッセージはクライアント識別子オプションを含まなくてはな
りません(MUST)、そしてクライアント識別子オプションの中身はクライアン
トのＤＵＩＤに一致しなくてはなりません(MUST)；あるいは、もしクライア
ントが元のメッセージにクライアント識別子オプションを含めなかったなら、
応答メッセージはクライアント識別子オプションを含んではなりません
(MUST NOT)。
Servers and relay agents MUST discard any received Reply messages.
サーバとリレーエージェントが受信した応答メッセージを捨てなくてはな
りません(MUST)。
15.11. Reconfigure Message
15.11. 再設定メッセージ
Servers and relay agents MUST discard any received Reconfigure
messages.
サーバとリレーエージェントが受信した再設定メッセージを捨てなくてはな
りません(MUST)。
Clients MUST discard any Reconfigure messages that meets any of the
following conditions:
クライアントが次の状態のどれかになっている再設定メッセージを捨てなく
てはなりません(MUST)：
- the message was not unicast to the client.
メッセージはクライアントへのユニキャストでない。
- the message does not include a Server Identifier option.
メッセージはサーバ識別子オプションを含まない。
- the message does not include a Client Identifier option that
contains the client's DUID.
メッセージはクライアントのＤＵＩＤを含んでいるクライアント識別子オ
プションを含んでいない。
- the message does not contain a Reconfigure Message option and the
msg-type must be a valid value.
メッセージは再設定メッセージオプションを含まず、そしてメッセージタ
イプは無効な値である。
- the message includes any IA options and the msg-type in the
Reconfigure Message option is INFORMATION-REQUEST.
メッセージはＩＡオプションを含み、そして再設定メッセージオプション
のメッセージタイプが情報要求である。
- the message does not include DHCP authentication:
メッセージはＤＨＣＰ認証を含まない：
* the message does not contain an authentication option.
メッセージは認証オプションを含んでいない。
* the message does not pass the authentication validation
performed by the client.
メッセージはクライアントが行う認証確証を渡さない。
15.12. Information-request Message
15.12. 情報要求メッセージ
Clients MUST discard any received Information-request messages.
クライアントは受信した情報要求メッセージを捨てなくてはなりません(MUST)。
Servers MUST discard any received Information-request message that
meets any of the following conditions:
サーバが次の状態のどれかになっている受信した情報要求メッセージを捨て
なくてはなりません(MUST)：
- The message includes a Server Identifier option and the DUID in
the option does not match the server's DUID.
メッセージはサーバ識別子オプションを含み、そしてオプションのＤＵＩ
ＤはサーバのＤＵＩＤに一致しない。
- The message includes an IA option.
メッセージはＩＡオプションを含む。
15.13. Relay-forward Message
15.13. リレー転送メッセージ
Clients MUST discard any received Relay-forward messages.
クライアントが受信したリレー転送メッセージを捨てなくてはなりません。
15.14. Relay-reply Message
15.14. リレー応答メッセージ
Clients and servers MUST discard any received Relay-reply messages.
クライアントとサーバが受信したリレー応答メッセージを捨てなくてはな
りません(MUST)。
16. Client Source Address and Interface Selection
16. クライアントソースアドレスとインタフェース選択
When a client sends a DHCP message to the
All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the message
through the interface for which configuration information is being
requested. However, the client MAY send the message through another
interface attached to the same link, if and only if the client is
certain the two interfaces are attached to the same link. The client
MUST use a link-local address assigned to the interface for which it
is requesting configuration information as the source address in the
header of the IP datagram.
クライアントが全ＤＨＣＰリレーエージェントアンドサーバアドレスにＤＨ
ＣＰメッセージを送る時、メッセージを設定情報を求めるインタフェースを
通して送るべきです(SHOULD)。しかしながら、もしクライアントが２つのイ
ンタフェースが同じリンクに置かれることが確かである場合に限り、そして
その場合には必ず、クライアントがメッセージをもう１つの同じリンクに置
かれたインタフェースを通して送るかもしれません(MAY)。クライアントが
インタフェースに割り当てたリンクローカルアドレスを使用し(MUST)、ＩＰ
データグラムのヘッダのソースアドレスの設定情報を求めます。
When a client sends a DHCP message directly to a server using unicast
(after receiving the Server Unicast option from that server), the
source address in the header of the IP datagram MUST be an address
assigned to the interface for which the client is interested in
obtaining configuration and which is suitable for use by the server
in responding to the client.
（サーバからサーバユニキャストオプションを受け取った後で）クライアン
トが直接ユニキャストを使ってそのサーバにＤＨＣＰメッセージを送る時、
ＩＰデータグラムのヘッダのソースアドレスは、クライアントが設定情報を
得たいインタフェースに割り当てられるアドレスで、サーバからクライアン
トに返答することが適しているものに違いありません(MUST)。
17. DHCP Server Solicitation
17. ＤＨＣＰサーバ要請
This section describes how a client locates servers that will assign
addresses to IAs belonging to the client.
この章はクライアントが、クライアントのＩＡにアドレスを割り当てるであ
ろうサーバの場所を突き止める方法を、記述します。
The client is responsible for creating IAs and requesting that a
server assign IPv6 addresses to the IA. The client first creates an
IA and assigns it an IAID. The client then transmits a Solicit
message containing an IA option describing the IA. Servers that can
assign addresses to the IA respond to the client with an Advertise
message. The client then initiates a configuration exchange as
described in section 18.
クライアントはＩＡを作りサーバにＩＰｖ６アドレスをＩＡに割り当てるこ
とを要請する責任があります。クライアントは最初にＩＡを作り、そしてそ
れにＩＡＩＤを割り当てます。クライアントはそれからＩＡを記述してＩＡ
オプションを含んでいる要請メッセージを伝達します。アドレスをＩＡに割
り当てることができるサーバが広告メッセージでクライアントに返答します。
クライアントは、１８章で記述されるように、設定交換を始めます。
If the client will accept a Reply message with committed address
assignments and other resources in response to the Solicit message,
the client includes a Rapid Commit option (see section 22.14) in the
Solicit message.
もしクライアントが要請メッセージに応えて占有アドレス割当てと他の資源
を持つ応答メッセージを受け入れるなら、クライアントは（２２.１４章参
照）要請メッセージに即時委任オプションを含めます。
17.1. Client Behavior
17.1. クライアント行動
A client uses the Solicit message to discover DHCP servers configured
to assign addresses or return other configuration parameters on the
link to which the client is attached.
クライアントが接続するリンク上のアドレスを割り当てるか他の設定パラメー
タを返すＤＨＣＰサーバを発見するため、クライアントが要請メッセージを
使います。
17.1.1. Creation of Solicit Messages
17.1.1. 要請メッセージの生成
The client sets the "msg-type" field to SOLICIT. The client
generates a transaction ID and inserts this value in the
"transaction-id" field.
クライアントは「メッセージ種別」フィールドに要請を設定します。クライ
アントは取引識別子を生成し、そしてこの値を「取引識別子」フィールドに
挿入します。
The client MUST include a Client Identifier option to identify itself
to the server. The client includes IA options for any IAs to which
it wants the server to assign addresses. The client MAY include
addresses in the IAs as a hint to the server about addresses for
which the client has a preference. The client MUST NOT include any
other options in the Solicit message, except as specifically allowed
in the definition of individual options.
クライアントはサーバがクライアントを識別するクライアント識別子オプショ
ンを含めなくてはなりません(MUST)。クライアントはサーバがアドレスを割
り当ててくれることを望むＩＡのＩＡオプションを含みます。クライアント
はサーバへのヒントとしてクライアントが優先だと思うアドレスをＩＡにア
ドレスを含めてもよいです(MAY)。クライアントは、個別のオプションの定義
で特に許される以外に、要請メッセージにいかなるオプションも含めてはな
りません(MUST NOT)。
The client uses IA_NA options to request the assignment of non-
temporary addresses and uses IA_TA options to request the assignment
of temporary addresses. Either IA_NA or IA_TA options, or a
combination of both, can be included in DHCP messages.
クライアントは非臨時アドレスの割当てを求めるのにＩＡ＿ＮＡオプション
を使い、一時的アドレスの割当てを求めるのにＩＡ＿ＴＡオプションを使い
ます。ＩＡ＿ＮＡあるいはＩＡ＿ＴＡオプションのどちらか、あるいは両方
の組合わせがＤＨＣＰメッセージに含ることができます。
The client SHOULD include an Option Request option (see section 22.7)
to indicate the options the client is interested in receiving. The
client MAY additionally include instances of those options that are
identified in the Option Request option, with data values as hints to
the server about parameter values the client would like to have
returned.
クライアントはクライアントが受信に興味を持っているオプションを示すた
めにオプション要求オプションを含めるべきです(SHOULD)（２２.７章参照）。
クライアントは、サーバへのヒントとして、オプション要求オプションで指
定したオプションについて、クライアントが返してもらいたいパラメータ値
を設定した実際のパラメータを設定してもよいです(MAY)。
The client includes a Reconfigure Accept option (see section 22.20)
if the client is willing to accept Reconfigure messages from the
server.
クライアントは、もしクライアントがサーバからの再設定メッセージの受信
を拒まないなら再設定受入オプションを含めます（２２.２０章参照）。
17.1.2. Transmission of Solicit Messages
17.1.2. 要請メッセージの伝達
The first Solicit message from the client on the interface MUST be
delayed by a random amount of time between 0 and SOL_MAX_DELAY. In
the case of a Solicit message transmitted when DHCP is initiated by
IPv6 Neighbor Discovery, the delay gives the amount of time to wait
after IPv6 Neighbor Discovery causes the client to invoke the
stateful address autoconfiguration protocol (see section 5.5.3 of RFC
2462). This random delay desynchronizes clients which start at the
same time (for example, after a power outage).
インタフェース上のクライアントからの最初の要請メッセージは０から
SOL_MAX_DELAYの間のランダム量の時間だけ遅らせられなくてはなりません。
ＤＨＣＰがＩＰｖ６近隣探索によって初期化され要請メッセージを送信する
場合、遅延は、ＩＰｖ６近隣探索がクライアントにステートフルアドレス自
動設定プロトコルを呼び出させた後の、待つ時間の量を与えます（ＲＦＣ２
４６２の５.５.３章参照）。このランダム遅延は（例えば、停電の後に）同
時に起動するクライアントを同期させないようにします。
The client transmits the message according to section 14, using the
following parameters:
クライアントは、１４章に従って、次のパラメータを使ってメッセージを伝
達します：
IRT SOL_TIMEOUT
MRT SOL_MAX_RT
MRC 0
MRD 0
If the client has included a Rapid Commit option in its Solicit
message, the client terminates the waiting process as soon as a Reply
message with a Rapid Commit option is received.
もしクライアントが要請メッセージに速い委任オプションを含めたなら、ク
ライアントは、即時委任オプションを持つ応答メッセージを受信するとすぐ
に待ち受けプロセスを終えます。
If the client is waiting for an Advertise message, the mechanism in
section 14 is modified as follows for use in the transmission of
Solicit messages. The message exchange is not terminated by the
receipt of an Advertise before the first RT has elapsed. Rather, the
client collects Advertise messages until the first RT has elapsed.
Also, the first RT MUST be selected to be strictly greater than IRT
by choosing RAND to be strictly greater than 0.
もしクライアントが広告メッセージを待つなら、１４章のメカニズムは要請
メッセージの伝達で使用するために次のように修正されます。メッセージ交
換は、最初のＲＴが経過する前の広告の受信では終わりません。どちらかと
言うと、クライアントは、最初のＲＴが経過するまで、広告を集めます。同
じく、厳密に０より大きいRANDを選択することで、最初のＲＴはＩＲＴより
厳密に大きく選ばれなくてはなりません(MUST)。
A client MUST collect Advertise messages for the first RT seconds,
unless it receives an Advertise message with a preference value of
255. The preference value is carried in the Preference option
(section 22.8). Any Advertise that does not include a Preference
option is considered to have a preference value of 0. If the client
receives an Advertise message that includes a Preference option with
a preference value of 255, the client immediately begins a client-
initiated message exchange (as described in section 18) by sending a
Request message to the server from which the Advertise message was
received. If the client receives an Advertise message that does not
include a Preference option with a preference value of 255, the
client continues to wait until the first RT elapses. If the first RT
elapses and the client has received an Advertise message, the client
SHOULD continue with a client-initiated message exchange by sending a
Request message.
クライアントは優先値が２５５の広告メッセージを受け取らない限り、最初
のＲＴ秒間に広告メッセージを集めなくてはなりません(MUST)。優先値は優
先オプション（２２.８章）で運ばれます。優先オプションを含まない広告は
０の優先値を持つと考えられます。もしクライアントが２５５の優先値の優
先オプションを含む広告メッセージを受信するなら、クライアントはすぐに
広告メッセージを送ってきたサーバに要求メッセージを送ることでクライア
ントによって始められたメッセージ交換を始めます（１８章で記述されるよ
うに）。もしクライアントが優先値２５５の優先オプションを含まない広告
メッセージを受け取るなら、クライアントは、最初のＲＴが経過するまで、
待ち続けます。もし最初のＲＴが経過し、そしてクライアントが広告メッセー
ジを受け取ったなら、クライアントは要求メッセージを送ることによってク
ライアントによって始められたメッセージ交換を続けるべきです(SHOULD)。
If the client does not receive any Advertise messages before the
first RT has elapsed, it begins the retransmission mechanism
described in section 14. The client terminates the retransmission
process as soon as it receives any Advertise message, and the client
acts on the received Advertise message without waiting for any
additional Advertise messages.
もしクライアントが、最初のＲＴが経過する前に、広告メッセージを受信し
ないなら、１４章で記述された再送機構を始めます。クライアントは、広告
メッセージを受け取るとすぐに、再送プロセスを終えます、そしてクライア
ントは追加の広告メッセージを待たないで受信したメッセージに対して行動
します。
A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client
is configured with either MRC or MRD set to a value other than 0, it
MUST stop trying to configure the interface if the message exchange
fails. After the DHCP client stops trying to configure the
interface, it SHOULD restart the reconfiguration process after some
external event, such as user input, system restart, or when the
client is attached to a new link.
ＤＨＣＰクライアントがＭＲＣとＭＲＤを０であるように選ぶべきです
(SHOULD)。もしＤＨＣＰクライアントが０以外の値を設定したＭＲＣかＭＲ
Ｄで設定されるなら、もしメッセージ交換が失敗するなら、インタフェース
の構成を設定しようとするのをやめなくてはなりません。ＤＨＣＰクライア
ントがインタフェースの構成を設定しようとするのをやめた後、ユーザ入力
やシステム再起動やクライアントが新しいリンクに置かれるなど、外部イベ
ントがおきた後に再設定プロセスを再開するべきです(SHOULD)。
17.1.3. Receipt of Advertise Messages
17.1.3. 広告メッセージの受信
The client MUST ignore any Advertise message that includes a Status
Code option containing the value NoAddrsAvail, with the exception
that the client MAY display the associated status message to the
user.
クライアントは、ユーザへ関連した状態メッセージを表示する以外は、
NoAddrsAvail値の状態コードオプションを含む広告メッセージを無視しなく
てはなりません。
Upon receipt of one or more valid Advertise messages, the client
selects one or more Advertise messages based upon the following
criteria.
１つ以上の正当な広告メッセージを受信したクライアントは次の基準の上に
基づいて１つ以上の広告メッセージを選択します。
- Those Advertise messages with the highest server preference value
are preferred over all other Advertise messages.
最も高いサーバ優先値を持つ広告メッセージがすべての他の広告メッセー
ジより優先します。
- Within a group of Advertise messages with the same server
preference value, a client MAY select those servers whose
Advertise messages advertise information of interest to the
client. For example, the client may choose a server that returned
an advertisement with configuration options of interest to the
client.
同じサーバ優先値の広告メッセージのグループの中で、クライアントが広
告メッセージ内でクライアントに興味のある情報を広告するサーバを選択
してもよいです。例えば、クライアントはクライアントに興味のある設定
オプションで広告を返したサーバを選択してもよいです。
- The client MAY choose a less-preferred server if that server has a
better set of advertised parameters, such as the available
addresses advertised in IAs.
クライアントは、ＩＡで利用可能なアドレスを広告するなど、もしサーバ
がよりよい広告パラメータを設定している場合、優先度の低いサーバを選
択してもよいです(MAY)。
Once a client has selected Advertise message(s), the client will
typically store information about each server, such as server
preference value, addresses advertised, when the advertisement was
received, and so on.
ひとたびクライアントが広告メッセージを選んだら、クライアントは一般に
それぞれのサーバに対し、サーバ優先値、広告されたアドレス、広告を受信
した時刻などの情報を記憶するでしょう。
If the client needs to select an alternate server in the case that a
chosen server does not respond, the client chooses the next server
according to the criteria given above.
もしクライアントが選ばれたサーバが返答しないという場合に代わりのサー
バを選ぶ必要があるなら、クライアントは上記の基準によって次のサーバを
選択します。
17.1.4. Receipt of Reply Message
17.1.4. 応答メッセージ受信
If the client includes a Rapid Commit option in the Solicit message,
it will expect a Reply message that includes a Rapid Commit option in
response. The client discards any Reply messages it receives that do
not include a Rapid Commit option. If the client receives a valid
Reply message that includes a Rapid Commit option, it processes the
message as described in section 18.1.8. If it does not receive such
a Reply message and does receive a valid Advertise message, the
client processes the Advertise message as described in section
17.1.3.
もしクライアントが要請メッセージに即時委任オプションを含めるなら、回
答に速い委任オプションを含む応答メッセージを期待するでしょう。クライ
アントは速い委任オプションを含まない応答メッセージを受信したら捨てま
す。もしクライアントが速い委任オプションを含む正当な応答メッセージを
受け取るなら、１８.１.８章で記述されるように、メッセージを処理します。
もしこのような応答メッセージを受信せず、そして正当な広告メッセージを
受信するなら、クライアントは１７.１.３章で記述されるように、広告メッ
セージを処理します。
If the client subsequently receives a valid Reply message that
includes a Rapid Commit option, it either:
もしクライアントがその後即時委任オプションを含む応答メッセージを受信
するなら：
processes the Reply message as described in section 18.1.8, and
discards any Reply messages received in response to the Request
message, or
１８.１.８章で記述されるように応答メッセージを処理し、そしてリクエ
ストメッセージに応えて受け取った応答メッセージを捨てる、あるいは
processes any Reply messages received in response to the Request
message and discards the Reply message that includes the Rapid
Commit option.
要求メッセージに応えて受信した応答メッセージを処理して、そして即時
委任オプションを含む応答メッセージを捨てます。
17.2. Server Behavior
17.2. サーバ行動
A server sends an Advertise message in response to valid Solicit
messages it receives to announce the availability of the server to
the client.
サーバが正当な要請メッセージに応えて、クライアントにサーバの有効性を
知らせる広告メッセージを送ります。
17.2.1. Receipt of Solicit Messages
17.2.1. 要請メッセージの受信
The server determines the information about the client and its
location as described in section 11 and checks its administrative
policy about responding to the client. If the server is not
permitted to respond to the client, the server discards the Solicit
message. For example, if the administrative policy for the server is
that it may only respond to a client that is willing to accept a
Reconfigure message, if the client indicates with a Reconfigure
Accept option in the Solicit message that it will not accept a
Reconfigure message, the servers discard the Solicit message.
サーバは、１１章で記述されるように、クライアントの情報とその場所を決
定して、そしてクライアントに返答する管理ポリシを調査します。もしサー
バがクライアントに返答するのを許されないなら、サーバーは要請メッセー
ジを捨てます。例えば、もしサーバの管理ポリシが、再設定メッセージの受
け入れることを拒まないクライアントにだけ返答してもよい、なら、もしク
ライアントが要請メッセージで再設定受入オプションで再設定メッセージの
受入れない事を示すなら、サーバは要請メッセージを捨てます。
If the client has included a Rapid Commit option in the Solicit
message and the server has been configured to respond with committed
address assignments and other resources, the server responds to the
Solicit with a Reply message as described in section 17.2.3.
Otherwise, the server ignores the Rapid Commit option and processes
the remainder of the message as if no Rapid Commit option were
present.
もしクライアントが要請メッセージに即時委任オプションを含め、そしてサー
バが占有アドレス割当てと他の資源を返答するように設定されたなら、サー
バは１７.２.３章で記述されるように、応答メッセージで要請に返答します。
さもなければ、サーバは速い委任オプションを無視して、速い委任オプショ
ンが存在していないかのように、メッセージの残りを処理します。
17.2.2. Creation and Transmission of Advertise Messages
17.2.2. 広告メッセージの生成と伝達
The server sets the "msg-type" field to ADVERTISE and copies the
contents of the transaction-id field from the Solicit message
received from the client to the Advertise message. The server
includes its server identifier in a Server Identifier option and
copies the Client Identifier from the Solicit message into the
Advertise message.
サーバは「メッセージ種別」フィールドを広告に定めて、そしてクライアン
トから受け取った要請メッセージの処理識別子フィールドの中身を広告メッ
セージにコピーします。サーバはサーバ識別子オプションにサーバ識別子を
含め、そして要請メッセージのクライアント識別子を広告メッセージにコピー
します。
The server MAY add a Preference option to carry the preference value
for the Advertise message. The server implementation SHOULD allow
the setting of a server preference value by the administrator. The
server preference value MUST default to zero unless otherwise
configured by the server administrator.
サーバは広告メッセージの優先値を運ぶ優先オプションを加えてもよいです
(MAY)。サーバ実装は管理者がサーバ優先値を設定するのを許すべきです
(SHOULD)。サーバ優先値は、サーバ管理者にに設定されないなら、ゼロをデ
フォルトとしなくてはなりません(MUST)。
The server includes a Reconfigure Accept option if the server wants
to require that the client accept Reconfigure messages.
もしサーバがクライアントに再設定メッセージを受け入れることを要求する
ことを望むなら、再設定受入オプションを含めます。
The server includes options the server will return to the client in a
subsequent Reply message. The information in these options may be
used by the client in the selection of a server if the client
receives more than one Advertise message. If the client has included
an Option Request option in the Solicit message, the server includes
options in the Advertise message containing configuration parameters
for all of the options identified in the Option Request option that
the server has been configured to return to the client. The server
MAY return additional options to the client if it has been configured
to do so. The server must be aware of the recommendations on packet
sizes and the use of fragmentation in section 5 of RFC 2460.
サーバは次の応答メッセージでサーバがクライアントに返すであろうオプショ
ンを含めます。これらのオプションの情報は、もしクライアントが１つ以上
の広告メッセージを受け取った場合の、サーバの選択のためにクライアント
によって使われるかもしれません。もしクライアントが要請メッセージにオ
プション要求オプションを含めたなら、サーバがクライアントに返すように
設定されたオプションの中からオプション要求で指定されたすべてのオプショ
ンの設定パラメータを含んでいるオプションを広告メッセージに含めます。
サーバーは、もしそうするように設定されたなら、クライアントに追加のオ
プションをを返してもよいです(MAY)。サーバはパケットサイズの推薦とＲＦ
Ｃ２４６０の５章の分割の使用に気付かなければなりません。
If the Solicit message from the client included one or more IA
options, the server MUST include IA options in the Advertise message
containing any addresses that would be assigned to IAs contained in
the Solicit message from the client. If the client has included
addresses in the IAs in the Solicit message, the server uses those
addresses as hints about the addresses the client would like to
receive.
もしクライアントからの要請メッセージに１つ以上のＩＡオプションが含れ
ているなら、サーバはクライアントからの要請メッセージに含まれるＩＡに
割り当てるアドレスを含むＩＡオプションを広告メッセージに含めなくては
なりません(MUST)。もしクライアントが要請メッセージにＩＡにアドレスを
含めたなら、サーバはクライアントが受け取りたいアドレスについてそれら
のアドレスをヒントとして用います。
If the server will not assign any addresses to any IAs in a
subsequent Request from the client, the server MUST send an Advertise
message to the client that includes only a Status Code option with
code NoAddrsAvail and a status message for the user, a Server
Identifier option with the server's DUID, and a Client Identifier
option with the client's DUID.
もしサーバがクライアントから次の要求でアドレスをＩＡに割り当てないな
ら、サーバはNoAddrsAvailコードとユーザへのメッセージを設定した状態コー
ドオプションと、サーバのＤＵＩＤを設定したサーバ識別子オプションと、
クライアントのＤＵＩＤを設定したクライアント識別子オプションだけ含む
広告メッセージをクライアントに送らなければなりません(MUST)。
If the Solicit message was received directly by the server, the
server unicasts the Advertise message directly to the client using
the address in the source address field from the IP datagram in which
the Solicit message was received. The Advertise message MUST be
unicast on the link from which the Solicit message was received.
もし要請メッセージがサーバへ直接きたら、サーバは要請メッセージを受信
したＩＰデータグラムのソースアドレスフィールド内のアドレスを使って、
クライアントに直接広告メッセージをユニキャストします。広告メッセージ
は要請メッセージを受信したリンク上のユニキャストであるに違いありませ
ん(MUST)。
If the Solicit message was received in a Relay-forward message, the
server constructs a Relay-reply message with the Advertise message in
the payload of a "relay-message" option. If the Relay-forward
messages included an Interface-id option, the server copies that
option to the Relay-reply message. The server unicasts the
Relay-reply message directly to the relay agent using the address in
the source address field from the IP datagram in which the Relay-
forward message was received.
もし要請メッセージがリレー転送メッセージで受け取られたなら、サーバは
「リレーメッセージ」オプションのペイロードに広告メッセージを設定した
リレー応答メッセージを組み立てます。もしリレー転送メッセージがインタ
フェース識別子オプションを含んでいたなら、サーバはリレー応答メッセー
ジにそのオプションをコピーします。サーバがリレー転送メッセージのＩＰ
データグラムのソースアドレスフィールドのアドレスを使って、直接リレー
エージェントへのリレー応答メッセージをユニキャストします。
17.2.3. Creation and Transmission of Reply Messages
17.2.3. 応答メッセージの生成と伝達
The server MUST commit the assignment of any addresses or other
configuration information message before sending a Reply message to a
client in response to a Solicit message.
サーバは要請メッセージに応えてクライアントに応答メッセージを送る前に
アドレスや他の設定情報メッセージの割当てを約束しなくてはなりません
(MUST)。
DISCUSSION:
論議：
When using the Solicit-Reply message exchange, the server commits
the assignment of any addresses before sending the Reply message.
The client can assume it has been assigned the addresses in the
Reply message and does not need to send a Request message for
those addresses.
要請−応答メッセージ交換を使う時、サーバは応答メッセージを送る前に
アドレスの割当てを約束します。クライアントは応答メッセージでアドレ
スを割り当てられ、そしてそれらのアドレスのために要求メッセージを送
る必要がないと想定することができます。
Typically, servers that are configured to use the Solicit-Reply
message exchange will be deployed so that only one server will
respond to a Solicit message. If more than one server responds,
the client will only use the addresses from one of the servers,
while the addresses from the other servers will be committed to
the client but not used by the client.
典型的に、要請−応答メッセージ交換を使うように設定されるサーバは、
ただ１つのサーバだけが要請メッセージに返答するように実装されるで
しょう。もし１つ以上のサーバが返答するなら、クライアントはサーバの
１つからのアドレスだけを使うでしょう、そして他のサーバからのアドレ
スはクライアントに委ねられるが、使われないでしょう。
The server includes a Rapid Commit option in the Reply message to
indicate that the Reply is in response to a Solicit message.
サーバは答えが要請メッセージの応答であることを示すため、応答メッセー
ジに即時委任オプションを含めます。
The server includes a Reconfigure Accept option if the server wants
to require that the client accept Reconfigure messages.
もしサーバがクライアントが再設定メッセージを受け入れることを要求する
ことを望むなら、サーバは再設定受入オプションを含めます。
The server produces the Reply message as though it had received a
Request message, as described in section 18.2.1. The server
transmits the Reply message as described in section 18.2.8.
サーバは、１８.２.１章で記述されるように、要求メッセージを受け取った
かのように、応答メッセージを作り出します。サーバは、１８.２.８で記述
されるように、応答メッセージを伝達します。
18. DHCP Client-Initiated Configuration Exchange
18. ＤＨＣＰクライアントによって始められた設定交換
A client initiates a message exchange with a server or servers to
acquire or update configuration information of interest. The client
may initiate the configuration exchange as part of the operating
system configuration process, when requested to do so by the
application layer, when required by Stateless Address
Autoconfiguration or as required to extend the lifetime of an address
(Renew and Rebind messages).
クライアントが興味の設定情報を獲得するか、あるいは更新するためにサー
バとメッセージ交換を始めます。クライアントは、アプリケーションレイヤ
によって要請される時や、ステートレスアドレス自動設定が要求する時や、
アドレスの寿命を延長するとき（更新と再結合メッセージ）、オペレーティ
ング・システム設定プロセスの一部として設定交換を始めてもよいです。
18.1. Client Behavior
18.1. クライアント行動
A client uses Request, Renew, Rebind, Release and Decline messages
during the normal life cycle of addresses. It uses Confirm to
validate addresses when it may have moved to a new link. It uses
Information-Request messages when it needs configuration information
but no addresses.
クライアントが標準的なライフサイクルの間に要求と更新と開放と再結合と
辞退メッセージを使います。クライアントは新しいリンクに動いたかもしれ
ない時、アドレスの妥当検査をするために確認を使います。クライアントは、
設定情報を必要とするが、アドレスを必要としないとき情報要求メッセージ
を使います。
If the client has a source address of sufficient scope that can be
used by the server as a return address, and the client has received a
Server Unicast option (section 22.12) from the server, the client
SHOULD unicast any Request, Renew, Release and Decline messages to
the server.
もしクライアントが返送先アドレスとしてサーバが使うことができる十分な
範囲のソースアドレスを持ち、そしてクライアントがサーバからサーバユニ
キャストオプション（２２.１２章）を受け取ったなら、サーバへの要求と更
新と開放と辞退メッセージでユニキャストをすべきです(SHOULD)。
DISCUSSION:
論議：
Use of unicast may avoid delays due to the relaying of messages by
relay agents, as well as avoid overhead and duplicate responses by
servers due to the delivery of client messages to multiple
servers. Requiring the client to relay all DHCP messages through
a relay agent enables the inclusion of relay agent options in all
messages sent by the client. The server should enable the use of
unicast only when relay agent options will not be used.
ユニキャストの使用は、リレーエージェントによるメッセージ中継の遅延
と、多数のサーバへのクライアントメッセージを配達する事によるサーバ
のコストとと重複回答を避けるかもしれません。クライアントにリレーエー
ジェントを通してすべてのＤＨＣＰメッセージを中継するように要求する
ことは、すべてのクライアントによって送られたメッセージでリレーエー
ジェントオプションを含めることを可能にします。サーバは、ただリレー
エージェントオプションが使われないであろう時だけ、ユニキャストの使
用を可能にするべきです。
18.1.1. Creation and Transmission of Request Messages
18.1.1. 要求メッセージの作成と伝達
The client uses a Request message to populate IAs with addresses and
obtain other configuration information. The client includes one or
more IA options in the Request message. The server then returns
addresses and other information about the IAs to the client in IA
options in a Reply message.
クライアントはＩＡにアドレスを入れて、そして他の設定情報を得るよため
要求メッセージを使います。クライアントはリクエストメッセージに１つ以
上のＩＡオプションを含めます。サーバは応答メッセージのＩＡオプション
でクライアントにＩＡについてのアドレスと他の情報を返します。
The client generates a transaction ID and inserts this value in the
"transaction-id" field.
クライアントは処理識別子を生成し、そしてこの値を「処理識別子」フィー
ルドに挿入します。
The client places the identifier of the destination server in a
Server Identifier option.
クライアントは宛先サーバの識別子をサーバ識別子オプションに置きます。
The client MUST include a Client Identifier option to identify itself
to the server. The client adds any other appropriate options,
including one or more IA options (if the client is requesting that
the server assign it some network addresses).
クライアントは、サーバがクライアント自身を識別するための、クライアン
ト識別子オプションを含めなくてはなりません(MUST)。クライアントは、
（もしクライアントがサーバからあるネットワークアドレスの割り当てるこ
とを要請しているなら）１つ以上のＩＡオプションを含めて、他の適切なオ
プションも加えます。
The client MUST include an Option Request option (see section 22.7)
to indicate the options the client is interested in receiving. The
client MAY include options with data values as hints to the server
about parameter values the client would like to have returned.
クライアントはクライアントが受信したいオプションを示すオプション要求
オプションを含めなければなりません(MUST)（２２.７章参照）。クライアン
トは得たいパラメータ値をサーバにヒントとして示すため、オプションを含
めるかもしれません(MAY)。
The client includes a Reconfigure Accept option (see section 22.20)
indicating whether or not the client is willing to accept Reconfigure
messages from the server.
クライアントがサーバーからの再設定メッセージの受信を受け入れるかどう
かを示すため（章参照）、クライアントは再設定受入オプションを含めます。
The client transmits the message according to section 14, using the
following parameters:
クライアントは、１４章に従って次のパラメータを使ってメッセージを伝達
します：
IRT REQ_TIMEOUT
MRT REQ_MAX_RT
MRC REQ_MAX_RC
MRD 0
If the message exchange fails, the client takes an action based on
the client's local policy. Examples of actions the client might take
include:
もしメッセージ交換が失敗するなら、クライアントはクライアントのローカ
ルなポリシーに基づいて行動をとります。クライアントがとるかもしれない
行動の例が以下を含みます：
- Select another server from a list of servers known to the client;
for example, servers that responded with an Advertise message.
クライアントに既知のサーバのリストから他のサーバを選択；例えば、広
告メッセージで応答したサーバー。
- Initiate the server discovery process described in section 17.
１７章で記述されたサーバ探索処理を開始。
- Terminate the configuration process and report failure.
設定処理を終えて、失敗を報告。
18.1.2. Creation and Transmission of Confirm Messages
18.1.2. 各章メッセージの生成と伝達
Whenever a client may have moved to a new link, the prefixes from the
addresses assigned to the interfaces on that link may no longer be
appropriate for the link to which the client is attached. Examples
of times when a client may have moved to a new link include:
クライアントが新しいリンクに動いた時は、前のリンク上でインタフェース
に割り当てられたアドレスのプレフィックスはもうクライアントが接続して
いるリンクに適切ではないかもしれません。クライアントが新しいリンに移
動したかもしれないときには、例えば、以下が含まれます：
o The client reboots.
クライアント再起動
o The client is physically connected to a wired connection.
クライアントが物理的にワイヤに接続
o The client returns from sleep mode.
クライアントはスリープモードから復帰
o The client using a wireless technology changes access points.
無線の技術を使っているクライアントがアクセスポイントを変更
In any situation when a client may have moved to a new link, the
client MUST initiate a Confirm/Reply message exchange. The client
includes any IAs assigned to the interface that may have moved to a
new link, along with the addresses associated with those IAs, in its
Confirm message. Any responding servers will indicate whether those
addresses are appropriate for the link to which the client is
attached with the status in the Reply message it returns to the
client.
クライアントが新しいリンクに動いたかもしれない状況の時、クライアント
は確認／応答メッセージ交換を始めなくてはなりません(MUST)。クライアン
トは新しいリンクに動いたかもしれないインターフェースに割当てられたＩ
Ａと、それらのＩＡに関連したアドレスを、確認メッセージに含めます。応
答をするサーバはクライアントが接続したリンクにそれらのアドレスが適当
かを、クライアントにか返す応答メッセージの状態で示すでしょう。
The client sets the "msg-type" field to CONFIRM. The client
generates a transaction ID and inserts this value in the
"transaction-id" field.
クライアントは「メッセージ種別」フィールドに確認を設定します。クライ
アントは処理識別子を生成し、そしてこの値を「処理識別子」フィールドに
挿入します。
The client MUST include a Client Identifier option to identify itself
to the server. The client includes IA options for all of the IAs
assigned to the interface for which the Confirm message is being
sent. The IA options include all of the addresses the client
currently has associated with those IAs. The client SHOULD set the
T1 and T2 fields in any IA_NA options, and the preferred-lifetime and
valid-lifetime fields in the IA Address options to 0, as the server
will ignore these fields.
クライアントはサーバがクライアント自身を識別するクライアント識別子オ
プションを含めなくてはなりません(MUST)。クライアントは確認メッセージ
を送るインタフェースに割り当てられた全てのＩＡのＩＡオプションを含め
ます。クライアントはIAに関連する全てのアドレスをＩＡオプションに含め
ます。クライアントはＩＡ＿ＮＡのＴ１とＴ２フィールドを設定し、ＩＡア
ドレスオプションの望ましい寿命と正式な寿命フィールドに、サーバがこれ
らのフィールドを無視するように、０を設定するべきです(SHOULD)。
The first Confirm message from the client on the interface MUST be
delayed by a random amount of time between 0 and CNF_MAX_DELAY. The
client transmits the message according to section 14, using the
following parameters:
インタフェース上のクライアントからの最初の確認メッセージは０から
CNF_MAX_DELAYの間のランダムな量の時間だけ遅らせらなくてはなりません
(MUST)。クライアントは、１４に従って、次のパラメータを使ってメッセー
ジを伝達します：
IRT CNF_TIMEOUT
MRT CNF_MAX_RT
MRC 0
MRD CNF_MAX_RD
If the client receives no responses before the message transmission
process terminates, as described in section 14, the client SHOULD
continue to use any IP addresses, using the last known lifetimes for
those addresses, and SHOULD continue to use any other previously
obtained configuration parameters.
もしクライアントが、１４章で記述されたように、メッセージ送信プロセス
が終わる前に回答を受け取らないなら、クライアントはそれらのアドレスの
ために最後の既知の寿命を使ってＩＰアドレスを使い続けるべき(SHOULD)で
あり、そして他の前に得られた設定パラメータも使い続けるべきです(SHOULD)。
18.1.3. Creation and Transmission of Renew Messages
18.1.3. 更新メッセージの送信と伝達
To extend the valid and preferred lifetimes for the addresses
associated with an IA, the client sends a Renew message to the server
from which the client obtained the addresses in the IA containing an
IA option for the IA. The client includes IA Address options in the
IA option for the addresses associated with the IA. The server
determines new lifetimes for the addresses in the IA according to the
administrative configuration of the server. The server may also add
new addresses to the IA. The server may remove addresses from the IA
by setting the preferred and valid lifetimes of those addresses to
zero.
ＩＡと結び付けられたアドレスの正当な寿命と望ましい寿命を延長するため
に、クライアントはＩＡのＩＡオプションを含む更新メッセージを、ＩＡの
アドレスを得たサーバに送ります。クライアントはＩＡと関連するアドレス
のＩＡオプションにＩＡアドレスオプションを含めます。サーバはサーバの
管理設定に従ってＩＡアドレスの新しい寿命を決定します。サーバは同じく
ＩＡに新しいアドレスを加えてもよいです。サーバはアドレスの正当な寿命
と望ましい寿命をゼロに設定することでアドレスをＩＡから取り除いてもよ
いです。
The server controls the time at which the client contacts the server
to extend the lifetimes on assigned addresses through the T1 and T2
parameters assigned to an IA.
サーバはIAに割当てたＴ１とＴ２パラメータにより、クライアントがアドレ
スに割り与えられている寿命を延長するためにサーバに連絡を取る時を制御
します。
At time T1 for an IA, the client initiates a Renew/Reply message
exchange to extend the lifetimes on any addresses in the IA. The
client includes an IA option with all addresses currently assigned to
the IA in its Renew message.
ＩＡの時刻Ｔ１において、クライアントはＩＡのアドレスの寿命を延長する
ために更新／応答メッセージ交換を始めます。クライアントはIAに割当てら
れた全てのアドレスのＩＡオプションを更新メッセージに含めます。
If T1 or T2 is set to 0 by the server (for an IA_NA) or there are no
T1 or T2 times (for an IA_TA), the client may send a Renew or Rebind
message, respectively, at the client's discretion.
もし（ＩＡ＿ＮＡに対して）Ｔ１かＴ２がサーバによって０を設定されるな
ら、あるいは（ＩＡ＿ＴＡに対して）Ｔ１あるいはＴ２時刻がないなら、ク
ライアントはそれぞれ、更新か再結合メッセージをクライアントの裁量で送
るかもしれません。
The client sets the "msg-type" field to RENEW. The client generates
a transaction ID and inserts this value in the "transaction-id"
field.
クライアントは「メッセージ種別」フィールドに更新を設定します。クライ
アントは処理識別子を生成し、そしてこの値を「処理識別子」フィールドに
設定します。
The client places the identifier of the destination server in a
Server Identifier option.
クライアントは宛先サーバの識別子をサーバ識別子オプションに設定します。
The client MUST include a Client Identifier option to identify itself
to the server. The client adds any appropriate options, including
one or more IA options. The client MUST include the list of
addresses the client currently has associated with the IAs in the
Renew message.
クライアントはサーバがクライアントを識別するクライアント識別子オプショ
ンを含めなくてはなりません(MUST)。クライアントは、１つ以上のＩＡオプ
ションを含めて、適切なオプションも加えます。クライアントは更新メッセー
ジに、現在クライアントがＩＡと関連して持ってるアドレスのリストを含め
なくてはなりません(MUST)。
The client MUST include an Option Request option (see section 22.7)
to indicate the options the client is interested in receiving. The
client MAY include options with data values as hints to the server
about parameter values the client would like to have returned.
クライアントは、クライアントが受信を望むオプションを示すためにオプショ
ン要求オプションを含めなければなりません(MUST)（２２.７章参照）。クラ
イアントはクライアントが得たいデータ値のサーバへのヒントのパラメータ
値を持つオプションを含めるかもしれません(MAY)。
The client transmits the message according to section 14, using the
following parameters:
クライアントは、１４章に従って、次のパラメータを使ってメッセージを伝
達します：
IRT REN_TIMEOUT
MRT REN_MAX_RT
MRC 0
MRD Remaining time until T2
The message exchange is terminated when time T2 is reached (see
section 18.1.4), at which time the client begins a Rebind message
exchange.
メッセージ交換は、時刻Ｔ２になると終了し（１８.１.４章参照）、その時
にクライアントは再結合メッセージ交換を始めます。
18.1.4. Creation and Transmission of Rebind Messages
18.1.4. 再結合メッセージの生成と伝達
At time T2 for an IA (which will only be reached if the server to
which the Renew message was sent at time T1 has not responded), the
client initiates a Rebind/Reply message exchange with any available
server. The client includes an IA option with all addresses
currently assigned to the IA in its Rebind message.
あるＩＡのＴ２時刻に（これはもし時刻Ｔ１に更新メッセージを送ったサー
バが応答しなかった場合に発生します）、クライアントは利用可能なサーバ
と再結合／応答メッセージ交換を始めます。クライアントはＩＡに割当てら
れている全てのアドレスを設定したＩＡオプションを再結合メッセージに含
めます。
The client sets the "msg-type" field to REBIND. The client generates
a transaction ID and inserts this value in the "transaction-id"
field.
クライアントは「メッセージ種別」フィールドを再結合に設定します。クラ
イアントは処理識別子を生成し、この値を「処理識別子」フィールドに設定
します。
The client MUST include a Client Identifier option to identify itself
to the server. The client adds any appropriate options, including
one or more IA options. The client MUST include the list of
addresses the client currently has associated with the IAs in the
Rebind message.
クライアントはサーバがクライアントを識別するクライアント識別子オプショ
ンを含めなくてはなりません(MUST)。クライアントは、１つ以上のＩＡオプ
ションを含め、適切なオプションを加えます。クライアントは再結合メッセー
ジに現在ＩＡと結び付いたクライアントの持つアドレスのリストを含めなく
てはなりません(MUST)。
The client MUST include an Option Request option (see section 22.7)
to indicate the options the client is interested in receiving. The
client MAY include options with data values as hints to the server
about parameter values the client would like to have returned.
クライアントは興味を持つオプションを示すためにオプション要求オプショ
ン（２２.７章参照）を含めなければなりません(MUST)。クライアントはクラ
イアントは得たいパラメータ値のサーバへのヒントとして、オプションを含
むかもしれません(MAY)。
The client transmits the message according to section 14, using the
following parameters:
クライアントは、１４章に従って、次のパラメータを使ってメッセージを伝
達します：
IRT REB_TIMEOUT
MRT REB_MAX_RT
MRC 0
MRD Remaining time until valid lifetimes of all addresses have
expired
The message exchange is terminated when the valid lifetimes of all
the addresses assigned to the IA expire (see section 10), at which
time the client has several alternative actions to choose from; for
example:
メッセージ交換はＩＡに割り当てられたすべてのアドレスの正式な寿命が期
限が切れた時に終わり（１０章参照）、この時クライアントが代わりの行動、
例えば次のどれかをします：
- The client may choose to use a Solicit message to locate a new
DHCP server and send a Request for the expired IA to the new
server.
クライアントは要請メッセージを使って新しいＤＨＣＰサーバと場所を突
き止め、新しいサーバに期限切れのＩＡに対する要求をします。
- The client may have other addresses in other IAs, so the client
may choose to discard the expired IA and use the addresses in the
other IAs.
クライアントは他のＩＡに他のアドレスを持ち、それでクライアントは期
限切れのＩＡを捨て、他のＩＡのアドレスを使います。
18.1.5. Creation and Transmission of Information-request Messages
18.1.5. 情報要求メッセージの生成と伝達
The client uses an Information-request message to obtain
configuration information without having addresses assigned to it.
クライアントはアドレスの割り当てなしに設定情報を得るため情報要求メッ
セージを使います。
The client sets the "msg-type" field to INFORMATION-REQUEST. The
client generates a transaction ID and inserts this value in the
"transaction-id" field.
クライアントは「メッセージ種別」フィールドを情報要求に設定します。ク
ライアントは処理識別子を生成して、そしてこの値を「処理識別子」フィー
ルドに挿入します。
The client SHOULD include a Client Identifier option to identify
itself to the server. If the client does not include a Client
Identifier option, the server will not be able to return any client-
specific options to the client, or the server may choose not to
respond to the message at all. The client MUST include a Client
Identifier option if the Information-Request message will be
authenticated.
クライアントはサーバがクライアントを識別するクライアント識別子オプショ
ンを含むべきです(SHOULD)。もしクライアントがクライアント識別子オプショ
ンを含まないなら、サーバはクライアントにクライアント特有のオプション
を返すことが可能ではないでしょう、あるいはサーバはまったくメッセージ
に返答しないことに決めてもよいです。クライアントは、もし情報要求メッ
セージが認証されるなら、クライアント識別子オプションを含まなくてはな
りません(MUST)。
The client MUST include an Option Request option (see section 22.7)
to indicate the options the client is interested in receiving. The
client MAY include options with data values as hints to the server
about parameter values the client would like to have returned.
クライアントは受信したいオプションを示すためにオプション要求オプショ
ン（２２.７章参照）を含めなければなりません(MUST)。クライアントはクラ
イアントが返てほしいパラメータ値についてのサーバへのヒントとしてデー
タ値を含むオプションを含めるかもしれません(MAY)。
The first Information-request message from the client on the
interface MUST be delayed by a random amount of time between 0 and
INF_MAX_DELAY. The client transmits the message according to section
14, using the following parameters:
インタフェース上のクライアントからの最初の情報要求メッセージは０から
INF_MAX_DELAYの間のランダム量の遅延をしなければなりません。クライアン
トは１４章に従って次のパラメータを使ってメッセージを伝達します：
IRT INF_TIMEOUT
MRT INF_MAX_RT
MRC 0
MRD 0
18.1.6. Creation and Transmission of Release Messages
18.1.6. 開放メッセージの生成と伝達
To release one or more addresses, a client sends a Release message to
the server.
１つ以上のアドレスを開放するために、クライアントがサーバに開放メッセー
ジを送ります。
The client sets the "msg-type" field to RELEASE. The client
generates a transaction ID and places this value in the
"transaction-id" field.
クライアントは「メッセージ種別」フィールドを開放に設定します。クライ
アントは処理識別子を生成し、この値を「処理識別子」フィールドに設定し
ます。
The client places the identifier of the server that allocated the
address(es) in a Server Identifier option.
クライアントはアドレスを割り当てたサーバの識別子をサーバ識別子オプ
ションに置きます。
The client MUST include a Client Identifier option to identify itself
to the server. The client includes options containing the IAs for
the addresses it is releasing in the "options" field. The addresses
to be released MUST be included in the IAs. Any addresses for the
IAs the client wishes to continue to use MUST NOT be added to the
IAs.
クライアントはサーバがクライアントを識別するクライアント識別子オプショ
ンを含めなくてはなりません(MUST)。クライアントは「オプション」フィー
ルドに開放するアドレスのＩＡを含むオプションを含めます。解放されるア
ドレスはＩＡに含められなくてはなりません(MUST)。クライアントが使い続
けたいＩＡのアドレスはＩＡに加えてはなりません(MUST NOT)。
The client MUST NOT use any of the addresses it is releasing as the
source address in the Release message or in any subsequently
transmitted message.
クライアントは開放メッセージやその後伝達されたメッセージで解放してい
るアドレスをソースアドレスとして用いてはなりません(MUST NOT)。
Because Release messages may be lost, the client should retransmit
the Release if no Reply is received. However, there are scenarios
where the client may not wish to wait for the normal retransmission
timeout before giving up (e.g., on power down). Implementations
SHOULD retransmit one or more times, but MAY choose to terminate the
retransmission procedure early.
開放メッセージが失われるかもしれないから、クライアントは、もし答えを
受け取れないなら、開放を再送するべきです。しかしながら、クライアント
があきらめる前に標準的な再送タイムアウトを待つことを望まないかもしれ
ないシナリオがあります（例えば、電源断）。実装が１回以上の再送をする
べきです(SHOULD)が、早く再送手順を終えることに決めてもよいです(MAY)。
The client transmits the message according to section 14, using the
following parameters:
クライアントは、１４章に従い、次のパラメータを使ってメッセージを伝達
します：
IRT REL_TIMEOUT
MRT 0
MRC REL_MAX_RC
MRD 0
The client MUST stop using all of the addresses being released as
soon as the client begins the Release message exchange process. If
addresses are released but the Reply from a DHCP server is lost, the
client will retransmit the Release message, and the server may
respond with a Reply indicating a status of NoBinding. Therefore,
the client does not treat a Reply message with a status of NoBinding
in a Release message exchange as if it indicates an error.
クライアントは開放メッセージ交換処理を始めるとすぐに、開放するアドレ
スのすべての使用をやめなくてはなりません(MUST)。もしアドレスが開放さ
れてＤＨＣＰサーバからの応答が失われるなら、クライアントは開放メッセー
ジを再送するでしょう、そしてサーバはNoBindingの状態を示す応答で返答し
てもよいです。それ故に、クライアントは開放メッセージ交換でNoBindingの
状態の応答メッセージをエラーを示すようには扱いません。
Note that if the client fails to release the addresses, each address
assigned to the IA will be reclaimed by the server when the valid
lifetime of that address expires.
もしクライアントがアドレスを開放し損ねるなら、ＩＡに割り当てた各アド
レスは、そのアドレスの正式な寿命の期限が切れる時、サーバに返還を要求
される事に注意してください。
18.1.7. Creation and Transmission of Decline Messages
18.1.7 辞退メッセージの生成と伝達
If a client detects that one or more addresses assigned to it by a
server are already in use by another node, the client sends a Decline
message to the server to inform it that the address is suspect.
もしサーバによって割り当てられたアドレスがすでに使用中であることをク
ライアントが感じ取るなら、クライアントはアドレスが疑わしいということ
を知らせるためにサーバに辞退メッセージを送ります。
The client sets the "msg-type" field to DECLINE. The client
generates a transaction ID and places this value in the
"transaction-id" field.
クライアントは「メッセージ種別」フィールドを辞退に設定します。クライ
アントは処理識別子を生成し、この値を「処理識別子」フィールドに設定し
ます。
The client places the identifier of the server that allocated the
address(es) in a Server Identifier option.
クライアントはアドレスを割り当てたサーバの識別子をサーバ識別子オプ
ションに設定します。
The client MUST include a Client Identifier option to identify itself
to the server. The client includes options containing the IAs for
the addresses it is declining in the "options" field. The addresses
to be declined MUST be included in the IAs. Any addresses for the
IAs the client wishes to continue to use should not be in added to
the IAs.
クライアントはサーバがクライアントを識別するクライアント識別子オプ
ションを含めなくてはなりません(MUST)。クライアントは「オプション」
フィールドに辞退するアドレスのＩＡを含んでいるオプションを含めます。
辞退するアドレスはＩＡに含められなくてはなりません(MUST)。クライアン
トが使い続けたいアドレスはＩＡに付け加えるべきではありません。
The client MUST NOT use any of the addresses it is declining as the
source address in the Decline message or in any subsequently
transmitted message.
クライアントは辞退したアドレスを、その後の辞退メッセージや他のメッ
セージでソースアドレスとして用いてはなりません(MUST NOT)。
The client transmits the message according to section 14, using the
following parameters:
クライアントは、１４章に従って、次のパラメータを使ってメッセージを
伝達します：
IRT DEC_TIMEOUT
MRT 0
MRC DEC_MAX_RC
MRD 0
If addresses are declined but the Reply from a DHCP server is lost,
the client will retransmit the Decline message, and the server may
respond with a Reply indicating a status of NoBinding. Therefore,
the client does not treat a Reply message with a status of NoBinding
in a Decline message exchange as if it indicates an error.
もしアドレスが辞退されたがＤＨＣＰサーバからの応答が失われるなら、ク
ライアントは辞退メッセージを再送するでしょう、そしてサーバはNoBinding
の状態を示す応答を返答してもよいです。それ故に、クライアントは辞退メッ
セージ交換でNoBindingの状態の応答メッセージをエラーを示すかのようには
扱いません。
18.1.8. Receipt of Reply Messages
18.1.8. 応答メッセージ受信
Upon the receipt of a valid Reply message in response to a Solicit
(with a Rapid Commit option), Request, Confirm, Renew, Rebind or
Information-request message, the client extracts the configuration
information contained in the Reply. The client MAY choose to report
any status code or message from the status code option in the Reply
message.
（即時委任オプション付きの）要請や要求や確証や更新や再結合や情報要求
メッセージに応えての正当な応答メッセージを受信したら、クライアントは
応答に含まれる設定情報を引き抜きます。クライアントは応答メッセージの
状態コードや状態コードオプションのメッセージを報告することに決めても
よいです(MAY)。
The client SHOULD perform duplicate address detection [17] on each of
the addresses in any IAs it receives in the Reply message before
using that address for traffic. If any of the addresses are found to
be in use on the link, the client sends a Decline message to the
server as described in section 18.1.7.
クライアントは応答メッセージで受取るＩＡのアドレスをトラフィックに使
う前に、アドレスの重複アドレス発見[21]を行うべきです(SHOULD)。もしア
ドレスのどれかがリンク上で使用中であることがわかるなら、クライアント
は、１８.１.７章で記述されるように、サーバに辞退メッセージを送ります。
If the Reply was received in response to a Solicit (with a Rapid
Commit option), Request, Renew or Rebind message, the client updates
the information it has recorded about IAs from the IA options
contained in the Reply message:
もし（即時委任オプション付きの）要請や要求や更新や再結合メッセージに
応えて応答が受け取られたなら、クライアントは応答メッセージのＩＡオプ
ションからのＩＡに関する記録された情報を更新します：
- Record T1 and T2 times.
Ｔ１とＴ２時刻の記録
- Add any new addresses in the IA option to the IA as recorded by
the client.
ＩＡオプションの新しいアドレスを、クライアントが記録したＩＡに追加
- Update lifetimes for any addresses in the IA option that the
client already has recorded in the IA.
クライアントがすでにＩＡに記録したＩＡオプションのアドレスの寿命を
更新
- Discard any addresses from the IA, as recorded by the client, that
have a valid lifetime of 0 in the IA Address option.
ＩＡアドレスオプションで正式な寿命が０のアドレスを、クライアントの
記録したＩＡから削除。
- Leave unchanged any information about addresses the client has
recorded in the IA but that were not included in the IA from the
server.
クライアントがＩＡに記録したアドレスでサーバがＩＡに含めたのでない
ものは、情報を変えないままにしておきます。
Management of the specific configuration information is detailed in
the definition of each option in section 22.
特定の設定情報の管理は２２章のそれぞれのオプションの定義で詳述されます。
If the client receives a Reply message with a Status Code containing
UnspecFail, the server is indicating that it was unable to process
the message due to an unspecified failure condition. If the client
retransmits the original message to the same server to retry the
desired operation, the client MUST limit the rate at which it
retransmits the message and limit the duration of the time during
which it retransmits the message.
もし状態コードがUnspecFailを含んでいる応答メッセージをクライアントが
受け取るなら、サーバが特定されていない失敗条件のためにメッセージを処
理することが不可能であったことを示しています。もしクライアントが望ま
しい運用の再開のため同じサーバへ元のメッセージを再送するなら、クライ
アントはメッセージの再送率と再送する期間を制限しなくてはなりません
(MUST)。
When the client receives a Reply message with a Status Code option
with the value UseMulticast, the client records the receipt of the
message and sends subsequent messages to the server through the
interface on which the message was received using multicast. The
client resends the original message using multicast.
値がUseMulticastの状態コードオプションを含む応答メッセージをクライア
ントが受け取る時、クライアントはメッセージの受信を記録し、マルチキャ
ストのメッセージを受信したインタフェースを通してサーバに次のメッセー
ジを送ります。クライアントはマルチキャストを使って元のメッセージを再
送します。
When the client receives a NotOnLink status from the server in
response to a Confirm message, the client performs DHCP server
solicitation, as described in section 17, and client-initiated
configuration as described in section 18. If the client receives any
Reply messages that do not indicate a NotOnLink status, the client
can use the addresses in the IA and ignore any messages that indicate
a NotOnLink status.
クライアントが確証メッセージの応答でサーバからNotOnLink状態を受け取る
時、クライアントは１７章で記述されるＤＨＣＰサーバ要請と、１８章で記
述されるクライアント初期設定を行います。もしクライアントがNotOnLink状
態ではない応答メッセージを受け取るなら、クライアントはＩＡのアドレスを
使い、そしてNotOnLink状態を示すメッセージを無視することができます。
When the client receives a NotOnLink status from the server in
response to a Request, the client can either re-issue the Request
without specifying any addresses or restart the DHCP server discovery
process (see section 17).
クライアントが要求に応えてサーバからNotOnLink状態を受け取る時、クライ
アントはアドレスを指定しないで要求を再発行するか、あるいはＤＨＣＰサー
バ探索プロセスを再開することができます（１７章参照）。
The client examines the status code in each IA individually. If the
status code is NoAddrsAvail, the client has received no usable
addresses in the IA and may choose to try obtaining addresses for the
IA from another server. The client uses addresses and other
information from any IAs that do not contain a Status Code option
with the NoAddrsAvail code. If the client receives no addresses in
any of the IAs, it may either try another server (perhaps restarting
the DHCP server discovery process) or use the Information-request
message to obtain other configuration information only.
クライアントはそれぞれのＩＡの状態コードを個々に調べます。もし状態コー
ドがNoAddrsAvailなら、クライアントはＩＡで有用なアドレスを受け取って
なく、そして他のサーバからＩＡのアドレスを得ようとすることに決めても
よいです。クライアントはNoAddrsAvailコードで状態コードオプションを含
んでいないＩＡのアドレスと他の情報を使います。もしクライアントがどの
ＩＡのアドレスも受け取らないなら、他のサーバを試みるか（多分ＤＨＣＰ
サーバ探索プロセスを再開して）、あるいは他の設定情報を得る情報要求メッ
セージを使うかもしれません。
When the client receives a Reply message in response to a Renew or
Rebind message, the client examines each IA independently. For each
IA in the original Renew or Rebind message, the client:
クライアントが更新あるいは再結合メッセージに応えて応答メッセージを受
け取る時、クライアントは独立にそれぞれのＩＡを調べます。元の更新や再
結合メッセージのそれぞれのＩＡに対し、クライアントは：
- sends a Request message if the IA contained a Status Code option
with the NoBinding status (and does not send any additional
Renew/Rebind messages)
もしＩＡがNoBinding状態の状態コードオプションを含むなら、要求メッ
セージを送ります（そして追加の更新／再結合メッセージを送りません）。
- sends a Renew/Rebind if the IA is not in the Reply message
もしＩＡが応答メッセージでないなら、更新／再結合を送ります。
- otherwise accepts the information in the IA
さもなければＩＡの情報を受け入れます。
When the client receives a valid Reply message in response to a
Release message, the client considers the Release event completed,
regardless of the Status Code option(s) returned by the server.
クライアントが開放メッセージに応えて正当な応答メッセージを受け取る時、
クライアントはサーバの返す状態コードオプションにかかわらず開放イベン
トが完了したと考えます。
When the client receives a valid Reply message in response to a
Decline message, the client considers the Decline event completed,
regardless of the Status Code option(s) returned by the server.
クライアントが辞退メッセージに応えて正当な応答メッセージを受け取る時、
クライアントはサーバの返す状態コードオプションにかかわらず辞退イベン
トが完了したと考えます。
18.2. Server Behavior
18.2. サーバ行動
For this discussion, the Server is assumed to have been configured in
an implementation specific manner with configuration of interest to
clients.
この議論のために、サーバはクライアントの興味をもつ設定を実装特定の方
法で設定されてると考えられます。たいていの例で、サーバはクライアント
メッセージに応えて応答を送るでしょう。
In most instances, the server will send a Reply in response to a
client message. This Reply message MUST always contain the Server
Identifier option containing the server's DUID and the Client
Identifier option from the client message if one was present.
この応答メッセージは、常にサーバのＤＵＩＤを含んでいるサーバ識別子オ
プションと、もし存在していればクライアントメッセージからのクライアン
ト識別子オプションを含んでいなくてはなりません(MUST)。
In most Reply messages, the server includes options containing
configuration information for the client. The server must be aware
of the recommendations on packet sizes and the use of fragmentation
in section 5 of RFC 2460. If the client included an Option Request
option in its message, the server includes options in the Reply
message containing configuration parameters for all of the options
identified in the Option Request option that the server has been
configured to return to the client. The server MAY return additional
options to the client if it has been configured to do so.
たいていの応答メッセージで、サーバはクライアントの設定情報を含むオプ
ションを含めます。サーバはＲＦＣ２４６０の５章のパケットサイズと分割
の用途の推薦に気付いているに違いありません。もしクライアントがメッセー
ジにオプション要求オプションを含めたなら、サーバは、サーバがクライア
ントに戻すように設定された全てのオプションのうち、オプション要求オプ
ションで指定されたオプションの設定パラメータを応答メッセージに含めま
す。サーバは、もしそうするように設定されたなら、クライアントに追加の
オプションを返してもよいです(MAY)。
18.2.1. Receipt of Request Messages
18.2.1. 要求メッセージの受信
When the server receives a Request message via unicast from a client
to which the server has not sent a unicast option, the server
discards the Request message and responds with a Reply message
containing a Status Code option with the value UseMulticast, a Server
Identifier option containing the server's DUID, the Client Identifier
option from the client message, and no other options.
サーバがユニキャストオプションを送らなかったクライアントからサーバが
ユニキャストで要求メッセージを受取るとき、サーバは要求メッセージを捨
て、UseMulticastの状態コードオプションとサーバのＤＵＩＤを含んでいる
サーバー識別子オプションとクライアントメッセージからのクライアント識
別子オプションだけを持つ応答メッセージを返します。
When the server receives a valid Request message, the server creates
the bindings for that client according to the server's policy and
configuration information and records the IAs and other information
requested by the client.
サーバが正当な要求メッセージを受け取る時、サーバはサーバのポリシーと
設定情報に従ってそのクライアントの結合を作り、そしてクライアントの求
めるＩＡと他の情報を記録します。
The server constructs a Reply message by setting the "msg-type" field
to REPLY, and copying the transaction ID from the Request message
into the transaction-id field.
サーバは「メッセージ種別」フィールドの応答を設定し、処理識別子フィー
ルドに要求メッセージから処理識別子をコピーすることで応答メッセージを
組み立てます。
The server MUST include a Server Identifier option containing the
server's DUID and the Client Identifier option from the Request
message in the Reply message.
サーバのＤＵＩＤを含んでいるサーバ識別子オプションと、要求メッセージ
からのクライアント識別子オプションを、応答メッセージに含めなくてはな
りません(MUST)。
If the server finds that the prefix on one or more IP addresses in
any IA in the message from the client is not appropriate for the link
to which the client is connected, the server MUST return the IA to
the client with a Status Code option with the value NotOnLink.
もしサーバがクライアントからのメッセージのＩＡのＩＰアドレスのプレ
フィックスがクライアントの接続するリンクに適切でないと気づいたら、
サーバはNotOnLink値の状態コードオプションと共にクライアントにＩＡを
帰さなくてはなりません(MUST)。
If the server cannot assign any addresses to an IA in the message
from the client, the server MUST include the IA in the Reply message
with no addresses in the IA and a Status Code option in the IA
containing status code NoAddrsAvail.
もしサーバがクライアントからのメッセージのＩＡのアドレスを割り当てる
ことができないなら、サーバはＩＡを応答メッセージに含め、状態コード
NoAddrsAvailを含むIAの状態コードオプションを含めなくてはなりません
(MUST)。
For any IAs to which the server can assign addresses, the server
includes the IA with addresses and other configuration parameters,
and records the IA as a new client binding.
サーバがアドレスを割り当てることができるＩＡのために、サーバはアドレ
スを含むＩＡと他の設定パラメータを含め、そしてＩＡを新しいクライアン
ト結合として記録します。
The server includes a Reconfigure Accept option if the server wants
to require that the client accept Reconfigure messages.
もしクライアントが再設定メッセージを受け入れることを要求することを
サーバが望むなら、サーバは再設定受入オプションを含めます。
The server includes other options containing configuration
information to be returned to the client as described in section
18.2.
サーバは１８.２章で記述されるように、クライアントに返される設定情報を
含む他のオプションを含めます。
If the server finds that the client has included an IA in the Request
message for which the server already has a binding that associates
the IA with the client, the client has resent a Request message for
which it did not receive a Reply message. The server either resends
a previously cached Reply message or sends a new Reply message.
もしクライアントが要求メッセージにＩＡを含め、それがサーバが既にクラ
イアントと結びついたＩＡの結合を持つ事にサーバが気づくなら、クライア
ントは応答メッセージを受け取らなかった要求メッセージを再送しました。
サーバは前にキャッシュされた応答メッセージを再送するか、あるいは新し
い応答メッセージを送ります。
18.2.2. Receipt of Confirm Messages
18.2.2. 確証メッセージ受信
When the server receives a Confirm message, the server determines
whether the addresses in the Confirm message are appropriate for the
link to which the client is attached. If all of the addresses in the
Confirm message pass this test, the server returns a status of
Success. If any of the addresses do not pass this test, the server
returns a status of NotOnLink. If the server is unable to perform
this test (for example, the server does not have information about
prefixes on the link to which the client is connected), or there were
no addresses in any of the IAs sent by the client, the server MUST
NOT send a reply to the client.
サーバが確証メッセージを受け取る時、サーバは確証メッセージのアドレス
がクライアントが接続するリンクに適切であるかどうか決定します。もし確
証メッセージでのアドレスのすべてがこのテストに合格するなら、サーバは
成功の状態を返します。もしアドレスのどれかがこのテストに合格しないな
ら、サーバはNotOnLinkの状態を返します。もしサーバがこのテストを行うこ
とが不可能であるか（例えば、サーバがクライアントが接続されているリン
クのプレフィックスの情報を持っていない）、あるいはクライアントによっ
て送られたＩＡのどれにもアドレスがなかったなら、サーバはクライアント
に答えを送ってはなりません(MUST NOT)。
The server ignores the T1 and T2 fields in the IA options and the
preferred-lifetime and valid-lifetime fields in the IA Address
options.
サーバはＩＡオプションのＴ１とＴ２フィールドとＩＡアドレスオプション
の望ましい寿命と正式な寿命フィールドを無視します。
The server constructs a Reply message by setting the "msg-type" field
to REPLY, and copying the transaction ID from the Confirm message
into the transaction-id field.
サーバは「メッセージ種別」フィールドを応答に設定し、処理識別子フィー
ルドに確証メッセージから処理識別子をコピーすることによって応答メッセー
ジを組み立てます。
The server MUST include a Server Identifier option containing the
server's DUID and the Client Identifier option from the Confirm
message in the Reply message. The server includes a Status Code
option indicating the status of the Confirm message.
サーバは応答メッセージに、サーバのＤＵＩＤを含んでいるサーバー識別子
オプションと、確証メッセージからのクライアント識別子オプションを、含
めなくてはなりません(MUST)。サーバは確証メッセージの状態を示す状態コー
ドオプションを含みます。
18.2.3. Receipt of Renew Messages
18.2.3. 更新メッセージ受信
When the server receives a Renew message via unicast from a client to
which the server has not sent a unicast option, the server discards
the Renew message and responds with a Reply message containing a
Status Code option with the value UseMulticast, a Server Identifier
option containing the server's DUID, the Client Identifier option
from the client message, and no other options.
サーバがユニキャストオプションを送らなかったクライアントから、サーバ
がユニキャストで更新メッセージを受け取る時、サーバは更新メッセージを
捨てて、UseMulticast値の状態コードオプションとサーバのＤＵＩＤを含ん
でいるサーバ識別子オプションとクライアントメッセージからのクライアン
ト識別子オプションのみを含んでいる応答メッセージを返します。
When the server receives a Renew message that contains an IA option
from a client, it locates the client's binding and verifies that the
information in the IA from the client matches the information stored
for that client.
サーバがクライアントからＩＡオプションを含んでいる更新メッセージを受
け取る時、クライアントの結合の場所を突き止めて、クライアントからのＩ
Ａの情報がそのクライアントのために保管された情報に一致することを確か
めます。
If the server cannot find a client entry for the IA the server
returns the IA containing no addresses with a Status Code option set
to NoBinding in the Reply message.
もしサーバがＩＡのクライアント項目を見いだすことができないなら、サー
バは応答メッセージの状態コードオプションにNoBindingを設定しアドレスを
含んでいないＩＡを返します。
If the server finds that any of the addresses are not appropriate for
the link to which the client is attached, the server returns the
address to the client with lifetimes of 0.
もしサーバがアドレスのどれかがクライアントが接続するリンクに適切では
ないことに気付くなら、サーバは０の寿命でクライアントにアドレスを返し
ます。
If the server finds the addresses in the IA for the client then the
server sends back the IA to the client with new lifetimes and T1/T2
times. The server may choose to change the list of addresses and the
lifetimes of addresses in IAs that are returned to the client.
もしサーバがクライアントのＩＡのアドレスを見いだすなら、サーバは新し
い寿命とＴ１／Ｔ２時刻でＩＡをクライアントに送り返します。サーバはク
ライアントに返すＩＡのアドレスのリストとアドレスの寿命を変えることに
決めてもよいです。
The server constructs a Reply message by setting the "msg-type" field
to REPLY, and copying the transaction ID from the Renew message into
the transaction-id field.
サーバは「メッセージ種別」フィールドを応答に設定し、処理識別子フィー
ルドの中に更新メッセージから処理識別子をコピーすることで応答メッセー
ジを組み立てます。
The server MUST include a Server Identifier option containing the
server's DUID and the Client Identifier option from the Renew message
in the Reply message.
サーバはサーバのＤＵＩＤを含んでいるサーバ識別子オプションと、更新メッ
セージからのクライアント識別子オプションを、応答メッセージに含めなく
てはなりません(MUST)。
The server includes other options containing configuration
information to be returned to the client as described in section
18.2.
サーバは１８.２章で記述されるように、クライアントに返される設定情報を
含む他のオプションを含めます。
18.2.4. Receipt of Rebind Messages
18.2.4. 再結合メッセージの受信
When the server receives a Rebind message that contains an IA option
from a client, it locates the client's binding and verifies that the
information in the IA from the client matches the information stored
for that client.
サーバがクライアントからＩＡオプションを含む再結合メッセージを受け取
る時、サーバはクライアントの結合を見つけ、そしてクライアントからのＩ
Ａ情報がクライアント用に保管された情報と一致することを確かめます。
If the server cannot find a client entry for the IA and the server
determines that the addresses in the IA are not appropriate for the
link to which the client's interface is attached according to the
server's explicit configuration information, the server MAY send a
Reply message to the client containing the client's IA, with the
lifetimes for the addresses in the IA set to zero. This Reply
constitutes an explicit notification to the client that the addresses
in the IA are no longer valid. In this situation, if the server does
not send a Reply message it silently discards the Rebind message.
もしサーバがＩＡのクライアント項目を見いだすことができなく、そしてサー
バの明示的な設定情報に従って、サーバがＩＡの中のアドレスがクライアン
トのインタフェースが接続するリンクに適切でないと決定するなら、サーバ
はＩＡの寿命をゼロに設定て、クライアントのＩＡを含む応答メッセージを
クライアントに送ってもよいです(MAY)。この応答はＩＡ中のアドレスがもう
正当ではないというクライアントへの明白な通知を形成します。この状態で、
もしサーバが応答メッセージを送らないなら、静かに再結合メッセージを捨
てます。
If the server finds that any of the addresses are no longer
appropriate for the link to which the client is attached, the server
returns the address to the client with lifetimes of 0.
もしサーバがアドレスのどれかがクライアントが接続するリンクに適切でな
いことに気付くなら、サーバは０の寿命でクライアントにアドレスを返しま
す。
If the server finds the addresses in the IA for the client then the
server SHOULD send back the IA to the client with new lifetimes and
T1/T2 times.
もしサーバがＩＡにクライアントのアドレスを見いだすなら、サーバは新し
い寿命とＴ１／Ｔ２時間でＩＡをクライアントに送り返すべきです(SHOULD)。
The server constructs a Reply message by setting the "msg-type" field
to REPLY, and copying the transaction ID from the Rebind message into
the transaction-id field.
サーバは「メッセージタイプ」フィールドを応答に設定し、取引識別子フィー
ルドの中に再結合メッセージからの取引識別子をコピーすることで応答メッ
セージを組み立てます。
The server MUST include a Server Identifier option containing the
server's DUID and the Client Identifier option from the Rebind
message in the Reply message.
サーバは応答メッセージに、サーバのＤＵＩＤを含むサーバ識別子オプショ
ンと、再結合メッセージからのクライアント識別子オプションを、含めなく
てはなりません(MUST)。
The server includes other options containing configuration
information to be returned to the client as described in section
18.2.
サーバは１８.２章に記述されるように、クライアントに返される設定情報
を含む他のオプションを含めます。
18.2.5. Receipt of Information-request Messages
18.2.5. 情報要求の受信
When the server receives an Information-request message, the client
is requesting configuration information that does not include the
assignment of any addresses. The server determines all configuration
parameters appropriate to the client, based on the server
configuration policies known to the server.
サーバが情報要求メッセージを受け取る時、クライアントはアドレスの割当
てなしで設定情報を求めています。サーバはクライアントに適切な、サーバ
が知っているサーバ設定ポリシーに基づいたすべての設定情報を決定します。
The server constructs a Reply message by setting the "msg-type" field
to REPLY, and copying the transaction ID from the Information-request
message into the transaction-id field.
サーバは「メッセージ種別」フィールドに応答を設定し、処理識別子フィー
ルドの中に情報要求メッセージから処理識別子をコピーすることによって応
答メッセージを組み立てます。
The server MUST include a Server Identifier option containing the
server's DUID in the Reply message. If the client included a Client
Identification option in the Information-request message, the server
copies that option to the Reply message.
サーバは応答メッセージにサーバのＤＵＩＤを含むサーバ識別子オプション
を含めなくてはなりません(MUST)。もしクライアントが情報要求メッセージ
にクライアント識別子オプションを含めたなら、サーバは応答メッセージに
そのオプションをコピーします。
The server includes options containing configuration information to
be returned to the client as described in section 18.2.
サーバは１８.２章で記述されるように、クライアントに返される設定情報を
含んでいるオプションを含めます。
If the Information-request message received from the client did not
include a Client Identifier option, the server SHOULD respond with a
Reply message containing any configuration parameters that are not
determined by the client's identity. If the server chooses not to
respond, the client may continue to retransmit the
Information-request message indefinitely.
もしクライアントから受け取る情報要求メッセージがクライアント識別子オ
プションを含まなかったなら、サーバは応答メッセージにクライアントの識
別子に依存せずに決定される設定パラメータでも含めて返答するべきです
(SHOULD)。もしサーバが応答しないことに決決定するなら、クライアントは
いつまでも情報要求メッセージを再び送り続けてもよいです。
18.2.6. Receipt of Release Messages
18.2.6. 開放メッセージ受信
When the server receives a Release message via unicast from a client
to which the server has not sent a unicast option, the server
discards the Release message and responds with a Reply message
containing a Status Code option with value UseMulticast, a Server
Identifier option containing the server's DUID, the Client Identifier
option from the client message, and no other options.
サーバがユニキャストオプションを送らなかったクライアントからユニキャ
ストで開放メッセージを受け取る時、サーバは開放メッセージを捨てて、そ
してUseMulticast値の状態コードと、サーバのＤＵＩＤを含んでいるサーバ
識別子オプションと、クライアントメッセージからのクライアント識別子オ
プションと、だけを含む応答メッセージで返答します。
Upon the receipt of a valid Release message, the server examines the
IAs and the addresses in the IAs for validity. If the IAs in the
message are in a binding for the client, and the addresses in the IAs
have been assigned by the server to those IAs, the server deletes the
addresses from the IAs and makes the addresses available for
assignment to other clients. The server ignores addresses not
assigned to the IA, although it may choose to log an error.
正しい開放メッセージを受信したら、サーバは検証のためにＩＡとＩＡのア
ドレスを調べます。もしメッセージのＩＡがクライアントと結合し、ＩＡの
アドレスがサーバからそのＩＡに割当てたものであるあんらば、サーバはＩ
Ａのアドレスを削除し、アドレスを他のクライアントに割り当て可能にしま
す。サーバは、エラーをログファイルに書くため以外は、ＩＡに割当てられ
ていないアドレスを無視します。
After all the addresses have been processed, the server generates a
Reply message and includes a Status Code option with value Success, a
Server Identifier option with the server's DUID, and a Client
Identifier option with the client's DUID. For each IA in the Release
message for which the server has no binding information, the server
adds an IA option using the IAID from the Release message, and
includes a Status Code option with the value NoBinding in the IA
option. No other options are included in the IA option.
すべてのアドレスが処理された後で、サーバは応答メッセージを生成し、
Success値を持つ状態コードオプションと、サーバのＤＵＩＤを設定したサー
バ識別オプションと、クライアントのＤＵＩＤを設定したクライアント識別
オプションを含みます。サーバが結合情報を持たない開放メッセージのＩＡ
に対して、サーバは開放メッセージのＩＡＩＤを使用してＩＡオプションを
追加し、ＩＡオプションにNoBinding値の状態コードを含めます。他のオプショ
ンはＩＡオプションにに含められません。
A server may choose to retain a record of assigned addresses and IAs
after the lifetimes on the addresses have expired to allow the server
to reassign the previously assigned addresses to a client.
アドレスの寿命が切れサーバが前にクライアントに割り当てたアドレスの再
割当をできるようになった後で、サーバーが割り当てられたアドレスとＩＡ
の記録を維持することに決めるかもしれません。
18.2.7. Receipt of Decline Messages
18.2.7. 辞退メッセージの受信
When the server receives a Decline message via unicast from a client
to which the server has not sent a unicast option, the server
discards the Decline message and responds with a Reply message
containing a Status Code option with the value UseMulticast, a Server
Identifier option containing the server's DUID, the Client Identifier
option from the client message, and no other options.
ユニキャストによってサーバがユニキャストオプションを送らなかったクラ
イアントからサーバが辞退メッセージを受け取る時、サーバは辞退メッセー
ジを捨てて、そしてUseMulticast値の状態コードオプションと、サーバのＤ
ＵＩＤを含んでいるサーバ識別子オプションと、クライアントメッセージか
らのクライアント識別子オプションのみを含む応答メッセージを返します。
Upon the receipt of a valid Decline message, the server examines the
IAs and the addresses in the IAs for validity. If the IAs in the
message are in a binding for the client, and the addresses in the IAs
have been assigned by the server to those IAs, the server deletes the
addresses from the IAs. The server ignores addresses not assigned to
the IA (though it may choose to log an error if it finds such an
address).
正しい自体メッセージを受信したサーバは、ＩＡとＩＡのアドレスを検証し
ます。もしメッセージでのＩＡがクライアントに結合していて、そしてＩＡ
のアドレスがサーバからＩＡに割り当てられたなら、サーバＩＡからアドレ
スを削除します。（もしこのようなアドレスを見いだすなら、エラーをログ
ファイルに書くかもしれなが）サーバはＩＡに割当てられていないアドレス
を無視します。
The client has found any addresses in the Decline messages to be
already in use on its link. Therefore, the server SHOULD mark the
addresses declined by the client so that those addresses are not
assigned to other clients, and MAY choose to make a notification that
addresses were declined. Local policy on the server determines when
the addresses identified in a Decline message may be made available
for assignment.
クライアントは辞退メッセージ中のアドレスがリンクで使用中なのを見つけ
ました。それ故に、サーバはアドレスを他のクライアントに割り当てること
がないように、辞退されたとしるしをつけるべきで(SHOULD)、アドレスが辞
退されたと通知をするかもしれません(MAY)。サーバのローカルポリシーが、
辞退メッセージで示されたアドレスを割当てに利用するか決定します。
After all the addresses have been processed, the server generates a
Reply message and includes a Status Code option with the value
Success, a Server Identifier option with the server's DUID, and a
Client Identifier option with the client's DUID. For each IA in the
Decline message for which the server has no binding information, the
server adds an IA option using the IAID from the Release message and
includes a Status Code option with the value NoBinding in the IA
option. No other options are included in the IA option.
すべてのアドレスが処理された後で、サーバは応答メッセージを生成して、
Success値の状態コードと、サーバのＤＵＩＤを持つサーバー識別子オプショ
ンと、クライアントのＤＵＩＤを持つクライアント識別子オプションを含め
ます。サーバ結合を持たない辞退メッセージの各ＩＡについて、サーバは開
放メッセージのＩＡＩＤを使用してＩＡオプションを追加し、NoBinding値の
状態コードオプションを含めます。他のオプションはＩＡオプションに含め
ません。
18.2.8. Transmission of Reply Messages
18.2.8. 応答メッセージの伝達
If the original message was received directly by the server, the
server unicasts the Reply message directly to the client using the
address in the source address field from the IP datagram in which the
original message was received. The Reply message MUST be unicast
through the interface on which the original message was received.
もし元のメッセージがサーバに直接届いたなら、サーバは元のメッセージの
ＩＰデータグラムのソースアドレスフィールドのアドレスを使ってクライア
ントに直接応答メッセージをユニキャストします。応答メッセージは、元の
メッセージを受信したインタフェースからのユニキャストでに違いありませ
ん(MUST)。
If the original message was received in a Relay-forward message, the
server constructs a Relay-reply message with the Reply message in the
payload of a Relay Message option (see section 22.10). If the
Relay-forward messages included an Interface-id option, the server
copies that option to the Relay-reply message. The server unicasts
the Relay-reply message directly to the relay agent using the address
in the source address field from the IP datagram in which the
Relay-forward message was received.
もし元のメッセージがリレー転送メッセージで受け取られたなら、サーバは
リレーメッセージオプションのペイロードでに応答メッセージを入れたリレー
応答メッセージを組み立てます（２２.１０章参照）。もしリレー転送メッセー
ジがインタフェースＩＤオプションを含むなら、サーバはリレー応答メッセー
ジにそのオプションをコピーします。サーバは受信したリレー転送メッセー
ジのIPデータグラムのソースアドレスフィールドのアドレスのリレーエー
ジェントにリレー転送メッセージを直接ユニキャストします。
19. DHCP Server-Initiated Configuration Exchange
19. ＤＨＣＰサーバからはじめる設定交換
A server initiates a configuration exchange to cause DHCP clients to
obtain new addresses and other configuration information. For
example, an administrator may use a server-initiated configuration
exchange when links in the DHCP domain are to be renumbered. Other
examples include changes in the location of directory servers,
addition of new services such as printing, and availability of new
software.
サーバがＤＨＣＰクライアントに新しいアドレスと他の設定情報を得させる
ために設定交換を始めます。例えば管理者がＤＨＣＰドメインのリンク番号
を付け直す時に、サーバが開始した設定交換を使ってもよいです。他の例で、
ディレクトリサーバの場所の変更や、プリントするような新しいサービスの
追加や、新しいソフトウェアの有効化です。
19.1. Server Behavior
19.1. サーバ動作
A server sends a Reconfigure message to cause a client to initiate
immediately a Renew/Reply or Information-request/Reply message
exchange with the server.
クライアントがサーバとすぐに更新／応答や情報要求／応答メッセージ交換
を始めさせるため、サーバが再設定メッセージを送ります。
19.1.1. Creation and Transmission of Reconfigure Messages
19.1.1. 再設定メッセージの生成と伝達
The server sets the "msg-type" field to RECONFIGURE. The server sets
the transaction-id field to 0. The server includes a Server
Identifier option containing its DUID and a Client Identifier option
containing the client's DUID in the Reconfigure message.
サーバは「メッセージ種別」フィールドを再設定に設定します。サーバは処
理識別子フィールドを０に設定します。サーバは再設定メッセージに、ＤＵ
ＩＤを含んでいるサーバ識別子オプションとクライアントのＤＵＩＤを含ん
でいるクライアント識別子オプションを含めます。
The server MAY include an Option Request option to inform the client
of what information has been changed or new information that has been
added. In particular, the server specifies the IA option in the
Option Request option if the server wants the client to obtain new
address information. If the server identifies the IA option in the
Option Request option, the server MUST include an IA option that
contains no other sub-options to identify each IA that is to be
reconfigured on the client.
どの情報が変更されたかあるいは追加された新しい情報を示すために、サー
バはオプション要求オプションを含めるかもしれません(MAY)。特に、もしク
ライアントが新しいアドレス情報を得ることをサーバが望むなら、サーバは
オプション要求オプションをＩＡオプションで指定します。もしサーバがオ
プション要求オプションでＩＡオプションを指定するなら、サーバはクライ
アント上で再設定されるはずであるＩＡを指定するオプションだけを含むＩ
Ａオプションを含まなくてはなりません(MUST)。
Because of the risk of denial of service attacks against DHCP
clients, the use of a security mechanism is mandated in Reconfigure
messages. The server MUST use DHCP authentication in the Reconfigure
message.
ＤＨＣＰクライアントに対してのサービス妨害攻撃の危険のため、セキュリ
ティ機構の使用は再設定メッセージで義務化されます。サーバは再設定メッ
セージでＤＨＣＰ認証を使わなくてはなりません(MUST)。
The server MUST include a Reconfigure Message option (defined in
section 22.19) to select whether the client responds with a Renew
message or an Information-Request message.
クライアントが更新メッセージあるいは情報要求メッセージに返答するかど
うか指定するために、サーバは再設定メッセージオプション（２２.１９章で
定義）を含めなくてはなりません(MUST)。
The server MUST NOT include any other options in the Reconfigure
except as specifically allowed in the definition of individual
options.
サーバは、個別のオプションの定義で特に許される以外に、再設定に他のい
かなるオプションも含めてはなりません(MUST NOT)。
A server sends each Reconfigure message to a single DHCP client,
using an IPv6 unicast address of sufficient scope belonging to the
DHCP client. If the server does not have an address to which it can
send the Reconfigure message directly to the client, the server uses
a Relay-reply message (as described in section 20.3) to send the
Reconfigure message to a relay agent that will relay the message to
the client. The server may obtain the address of the client (and the
appropriate relay agent, if required) through the information the
server has about clients that have been in contact with the server,
or through some external agent.
ＤＨＣＰクライアントに属している十分な範囲のＩＰｖ６ユニキャストアド
レスを使って、サーバが１つのＤＨＣＰクライアントにそれぞれに再設定メッ
セージを送ります。もしサーバが直接クライアントに再設定メッセージを送
ることができるアドレスを持っていないなら、サーバはクライアントにメッ
セージを伝えるであろうリレーのエージェントに再設定メッセージを送るリ
レー応答メッセージ（２０.３章で記述）を使います。サーバと連絡をとって
いたクライアントや、ある外部のエージェントを通して持っている情報を通
して、サーバはクライアント（と、もし必要とされるなら、適切なリレーエー
ジェント）のアドレスを得てもよいです。
To reconfigure more than one client, the server unicasts a separate
message to each client. The server may initiate the reconfiguration
of multiple clients concurrently; for example, a server may send a
Reconfigure message to additional clients while previous
reconfiguration message exchanges are still in progress.
１つ以上のクライアントを再設定するために、サーバは各クライアントに個
別にメッセージをユニキャストします。サーバは同時に多数のクライアント
の再設定を始めてもよいです；例えば、サーバが、前の再設定メッセージの
交換がまだ進行中である間に、追加のクライアントに再設定メッセージを送っ
てもよいです。
The Reconfigure message causes the client to initiate a Renew/Reply
or Information-request/Reply message exchange with the server. The
server interprets the receipt of a Renew or Information-request
message (whichever was specified in the original Reconfigure message)
from the client as satisfying the Reconfigure message request.
再設定メッセージはクライアントがサーバと更新／応答あるいは情報要求／
応答メッセージ交換を始めさせます。サーバはクライアントからの再設定メッ
セージに対応する更新あるいは情報要求メッセージ（どちらかは元の再設定
メッセージで指定）の受信を要求が満たされたと解釈します。
19.1.2. Time Out and Retransmission of Reconfigure Messages
19.1.2. タイムアウトと再設定メッセージの再送
If the server does not receive a Renew or Information-request message
from the client in REC_TIMEOUT milliseconds, the server retransmits
the Reconfigure message, doubles the REC_TIMEOUT value and waits
again. The server continues this process until REC_MAX_RC
unsuccessful attempts have been made, at which point the server
SHOULD abort the reconfigure process for that client.
もしサーバがREC_TIMEOUTミリ秒以内にクライアントから更新あるいは情報要
求メッセージを受け取らないなら、サーバは再設定メッセージを再び送って、
REC_TIMEOUT値を２倍にして、再び待ちます。サーバは、REC_MAX_RC回の不成
功の試みがされるまで、このプロセスを続けて、この点でサーバはクライア
ントの再設定処理を中止するべきです(SHOULD)。
Default and initial values for REC_TIMEOUT and REC_MAX_RC are
documented in section 5.5.
REC_TIMEOUTとREC_MAX_RCのデフォルトと最初の値が５.５章で文書化されま
す。
19.2. Receipt of Renew Messages
19.2. 更新メッセージの受信
The server generates and sends a Reply message to the client as
described in sections 18.2.3 and 18.2.8, including options for
configuration parameters.
１８.２.３章と１８.２.８章で記述されるように、サーバはクライアントへ
の設定パラメータのオプションを含む応答メッセージを生成して送ります。
The server MAY include options containing the IAs and new values for
other configuration parameters in the Reply message, even if those
IAs and parameters were not requested in the Renew message from the
client.
サーバは、たとえクライアントからの更新メッセージでＩＡとパラメータが
求められなかったとしても、応答メッセージにＩＡと他の設定パラメータの
新しい値を含めてもよいです(MAY)。
19.3. Receipt of Information-request Messages
19.3. 情報要求メッセージの受信
The server generates and sends a Reply message to the client as
described in sections 18.2.5 and 18.2.8, including options for
configuration parameters.
１８.２.５章と１８.２.８章で記述されるように、サーバはクライアントに
設定パラメータのオプションを含む応答メッセージを生成して送ります。
The server MAY include options containing new values for other
configuration parameters in the Reply message, even if those
parameters were not requested in the Information-request message from
the client.
サーバは、たとえクライアントからの更新メッセージでパラメータが求めら
れなかったとしても、応答メッセージに他の設定パラメータの新しい値を含
めてもよいです(MAY)。
19.4. Client Behavior
19.4. クライアント動作
A client receives Reconfigure messages sent to the UDP port 546 on
interfaces for which it has acquired configuration information
through DHCP. These messages may be sent at any time. Since the
results of a reconfiguration event may affect application layer
programs, the client SHOULD log these events, and MAY notify these
programs of the change through an implementation-specific interface.
クライアントがＤＨＣＰをから設定情報を獲得したインタフェース上のＵＤ
Ｐポート５４６に送られた再設定メッセージを受け取ります。これらのメッ
セージはいつでも送られるかもしれません。再設定イベントの結果がアプリ
ケーションレイヤプログラムに影響を与えるかもしれないので、クライアン
トはこれらのイベントをログファイルに書くべき(SHOULD)であって、そして
実装特有のインタフェースを通してこれらの変更をプログラムに知らせても
よいです(MAY)。
19.4.1. Receipt of Reconfigure Messages
19.4.1. 再設定メッセージの受信
Upon receipt of a valid Reconfigure message, the client responds with
either a Renew message or an Information-request message as indicated
by the Reconfigure Message option (as defined in section 22.19). The
client ignores the transaction-id field in the received Reconfigure
message. While the transaction is in progress, the client silently
discards any Reconfigure messages it receives.
正当な再設定メッセージを受信したクライアントは、再設定メッセージオプ
ション（２２.１９章で定義される）で示されるように、更新メッセージある
いは情報要求メッセージで返答します。クライアントは受信した再設定メッ
セージの処理識別子フィールドを無視します。処理が進行中である間に、ク
ライアントは静かに受け取る再設定メッセージを捨てます。
DISCUSSION:
論議：
The Reconfigure message acts as a trigger that signals the client
to complete a successful message exchange. Once the client has
received a Reconfigure, the client proceeds with the message
exchange (retransmitting the Renew or Information-request message
if necessary); the client ignores any additional Reconfigure
messages until the exchange is complete. Subsequent Reconfigure
messages cause the client to initiate a new exchange.
再設定メッセージはクライアントにメッセージ交換の成功の終了の信号を
送る引き金の役を務めます。クライアントが再設定を受け取ったら、クラ
イアントは（もし必要なら、更新や情報要求メッセージを再送して）メッ
セージ交換を続けます；クライアントは、交換が完全になるまで、追加の
再設定メッセージを無視します。次の再設定メッセージがクライアントに
新しい交換を始めさせます。
How does this mechanism work in the face of duplicated or
retransmitted Reconfigure messages? Duplicate messages will be
ignored because the client will begin the exchange after the
receipt of the first Reconfigure. Retransmitted messages will
either trigger the exchange (if the first Reconfigure was not
received by the client) or will be ignored. The server can
discontinue retransmission of Reconfigure messages to the client
once the server receives the Renew or Information-request message
from the client.
重複や再送の再設定メッセージに対して、このメカニズムが働くでしょう
か？重複メッセージが、クライアントが最初の再設定の受信後にメッセー
ジ交換を始めるであろうから、無視されるでしょう。再送メッセージは、
メッセージ交換を起こすか（もし最初の再設定をクライアントが受信しな
ければ）、あるいは無視されるでしょう。サーバがクライアントから更新
や情報要求メッセージを受け取る途端に、サーバはクライアントへの再設
定メッセージの再送を中止することができます。
It might be possible for a duplicate or retransmitted Reconfigure
to be sufficiently delayed (and delivered out of order) to arrive
at the client after the exchange (initiated by the original
Reconfigure) has been completed. In this case, the client would
initiate a redundant exchange. The likelihood of delayed and out
of order delivery is small enough to be ignored. The consequence
of the redundant exchange is inefficiency rather than incorrect
operation.
重複や再送の再設定がかなり遅れて（そして順序どおりに配達されなく
て）、（最初の再設定によって始められた）交換が終わった後に、クライ
アントに到達することがありえます。この場合、クライアントは重複する
交換を始めるでしょう。遅延と順序どおりでない配達の可能性は無視出来
るほど十分小さいです。重複する交換の結果は正しくない運用ではなくど
ちらかと言うと、非能率です。
19.4.2. Creation and Transmission of Renew Messages
19.4.2. 更新メッセージの生成と伝達
When responding to a Reconfigure, the client creates and sends the
Renew message in exactly the same manner as outlined in section
18.1.3, with the exception that the client copies the Option Request
option and any IA options from the Reconfigure message into the Renew
message.
再設定に応答する時、クライアントが再設定メッセージのオプション要求オ
プションとＩＡオプションを更新メッセージにコピーするのを例外として、
クライアントは１８.１.３章で正確に説明されるのと同じ方法で更新メッセー
ジを作って送ります。
19.4.3. Creation and Transmission of Information-request Messages
19.4.3. 情報要求メッセージの生成と伝達
When responding to a Reconfigure, the client creates and sends the
Information-request message in exactly the same manner as outlined in
section 18.1.5, with the exception that the client includes a Server
Identifier option with the identifier from the Reconfigure message to
which the client is responding.
再設定に応答する時、クライアントが再設定メッセージの識別子でサーバ識
別子オプションを含めるのを例外として、クライアントは正確に１８.１.５
章で概説されると比べて同じ方法で情報要求メッセージを作って送ります。
19.4.4. Time Out and Retransmission of Renew or Information-request
Messages
19.4.4. タイムアウトと更新や情報要求メッセージの再送
The client uses the same variables and retransmission algorithm as it
does with Renew or Information-request messages generated as part of
a client-initiated configuration exchange. See sections 18.1.3 and
18.1.5 for details. If the client does not receive a response from
the server by the end of the retransmission process, the client
ignores and discards the Reconfigure message.
クライアントは、クライアントから始めた設定交換での更新や情報交換メッ
セージで使ったのと同じ変数と再送アルゴリズムを使います。詳細は
１８.１.３章と１８.１.５章を見てください。もしクライアントが再送処理
のの終わりまでにサーバから回答を受け取らないなら、クライアントは再設
定メッセージを無視して、そして捨てます。
19.4.5. Receipt of Reply Messages
19.4.5. 応答メッセージの受信
Upon the receipt of a valid Reply message, the client processes the
options and sets (or resets) configuration parameters appropriately.
The client records and updates the lifetimes for any addresses
specified in IAs in the Reply message.
正しい応答メッセージを受信したクライアントはオプションを処理して、適
切に設定パラメータを設定（あるいはリセット）します。クライアントは応
答メッセージのＩＡで指定されたアドレスの寿命を記録や更新します。
20. Relay Agent Behavior
20. リレーエージェント動作
The relay agent MAY be configured to use a list of destination
addresses, which MAY include unicast addresses, the All_DHCP_Servers
multicast address, or other addresses selected by the network
administrator. If the relay agent has not been explicitly
configured, it MUST use the All_DHCP_Servers multicast address as the
default.
リレーエージェントは宛先アドレスのリストを使うように設定されるかもし
れず(MAY)、そしてそれはユニキャストアドレスやAll_DHCP_Serversマルチ
キャストアドレスやネットワーク管理者によって選択された他のアドレスを
含むかもしれません(MAY)。もしリレーエージェントが明示的に設定されな
かったなら、All_DHCP_Serversマルチキャストアドレスをデフォルトとして
用いなくてはなりません(MUST)。
If the relay agent relays messages to the All_DHCP_Servers multicast
address or other multicast addresses, it sets the Hop Limit field to
32.
もしリレーエージェントがAll_DHCP_Serversマルチキャストアドレスあるい
は他のマルチキャストアドレスへのメッセージを中継するなら、それはホッ
プ限界フィールドを３２にセットします。
20.1. Relaying a Client Message or a Relay-forward Message
20.1. クライアントメッセージやリレー転送メッセージの中継
A relay agent relays both messages from clients and Relay-forward
messages from other relay agents. When a relay agent receives a
valid message to be relayed, it constructs a new Relay-forward
message. The relay agent copies the source address from the header
of the IP datagram in which the message was received to the
peer-address field of the Relay-forward message. The relay agent
copies the received DHCP message (excluding any IP or UDP headers)
into a Relay Message option in the new message. The relay agent adds
to the Relay-forward message any other options it is configured to
include.
リレーエージェントがクライアントからのメッセージと他のリレーエージェ
ントからのリレー転送メッセージの両方を中継します。リレーエージェント
が中継する正しいメッセージを受け取る時、新しいリレー中継メッセージを
組み立てます。リレーエージェントはメッセージを受け取ったＩＰデータグ
ラムのヘッダーのソースアドレスから、リレー転送メッセージの相手アドレ
スフィールドにコピーをします。リレーエージェントは新しいメッセージの
リレーメッセージオプションの中に（ＩＰあるいはＵＤＰヘッダを除いた）
受信ＤＨＣＰメッセージをコピーします。リレーエージェントは、含めるよ
うに設定された他のオプションを、転送メッセージに付け加えます。
20.1.1. Relaying a Message from a Client
20.1.1. クライアントからのメッセージの中継
If the relay agent received the message to be relayed from a client,
the relay agent places a global or site-scoped address with a prefix
assigned to the link on which the client should be assigned an
address in the link-address field. This address will be used by the
server to determine the link from which the client should be assigned
an address and other configuration information. The hop-count in the
Relay-forward message is set to 0.
もしリレーエージェントがクライアントから中継メッセージを受け取ったな
ら、リレーエージェントは、クライアントがアドレスを割り当てられるべき
であるリンクに割り当てられたプレフィックスを持つグローバルか、あるい
はサイト範囲のアドレスをリンクアドレスフィールドに設定します。このア
ドレスは、クライアントのアドレスや他の設定情報を割り当てるべきリンク
を決定するために、サーバーによって使われるでしょう。リレー転送メッセー
ジのホップカウントは０に設定されます。
If the relay agent cannot use the address in the link-address field
to identify the interface through which the response to the client
will be relayed, the relay agent MUST include an Interface-id option
(see section 22.18) in the Relay-forward message. The server will
include the Interface-id option in its Relay-reply message. The
relay agent fills in the link-address field as described in the
previous paragraph regardless of whether the relay agent includes an
Interface-id option in the Relay-forward message.
もしリレーエージェントがクライアントに対する応答を中継するインタフェー
スを識別するためのリンクアドレスフィールドのアドレスを使うことができ
ないなら、リレーエージェントはインタフェース識別子オプション
（２２.１８章参照）をリレー転送メッセージに含めなくてはなりません
(MUST)。サーバはそのリレー応答メッセージにインタフェース識別子オプショ
ンを含めるでしょう。リレーエージェントがリレー転送メッセージにインタ
フェース識別子オプションを含めるかどうかにかかわらず、リレーエージェ
ントは前の段落で記述されるように、リンクアドレスフィールドを記入しま
す。
20.1.2. Relaying a Message from a Relay Agent
20.1.2. リレーエージェントからの中継メッセージ
If the message received by the relay agent is a Relay-forward message
and the hop-count in the message is greater than or equal to
HOP_COUNT_LIMIT, the relay agent discards the received message.
もしリレーエージェントの受け取ったメッセージがリレー転送メッセージで
あり、そしてメッセージでのホップカウントがHOP_COUNT_LIMITかそれ以上で
あるなら、リレーエージェントは受信したメッセージを捨てます。
The relay agent copies the source address from the IP datagram in
which the message was received from the client into the peer-address
field in the Relay-forward message and sets the hop-count field to
the value of the hop-count field in the received message incremented
by 1.
リレーエージェントは、クライアントから受信したメッセージのＩＰデータ
グラムのソースアドレスを、リレー転送メッセージの相手アドレスフィール
ドにコピーし、ホップカウントフィールドの値を受信した値から１増やして
設定します。
If the source address from the IP datagram header of the received
message is a global or site-local address (and the device on which
the relay agent is running belongs to only one site), the relay agent
sets the link-address field to 0; otherwise the relay agent sets the
link-address field to a global or site-local address assigned to the
interface on which the message was received, or includes an
Interface-ID option to identify the interface on which the message
was received.
もし受信メッセージのＩＰデータグラムヘッダのソースアドレスがグローバ
ルかサイトローカルアドレス（そしてリレーエージェントが動作する装置が
１つのサイトだけに属する）なら、リレーエージェントはリンクアドレス
フィールドを０に設定します；さもなければリレーエージェントはリンクア
ドレスフィールドをメッセージを受信したインタフェースに割り当てられた
グローバルかサイトローカルなアドレスに設定するか、メッセージが受取っ
たインタフェースを識別するインタフェース識別子オプションを含めます。
20.2. Relaying a Relay-reply Message
20.2. リレー応答メッセージの中継
The relay agent processes any options included in the Relay-reply
message in addition to the Relay Message option, and then discards
those options.
リレーエージェントはリレーメッセージオプションのほかのリレー応答メッ
セージに含められたオプションを処理して、次にそれらのオプションを捨て
ます。
The relay agent extracts the message from the Relay Message option
and relays it to the address contained in the peer-address field of
the Relay-reply message.
リレーエージェントはリレーメッセージオプションからのメッセージを引き
抜いて、そしてリレー応答メッセージの相手アドレスフィールドに含まれる
アドレスにそれらを中継します。
If the Relay-reply message includes an Interface-id option, the relay
agent relays the message from the server to the client on the link
identified by the Interface-id option. Otherwise, if the
link-address field is not set to zero, the relay agent relays the
message on the link identified by the link-address field.
もしリレー応答メッセージがインタフェース識別子オプションを含むなら、
リレーのエージェントはインタフェース識別子オプションによって識別され
たリンク上のクライアントにサーバからのメッセージを伝えます。さもなけ
れば、もしリンクアドレスフィールドがゼロに設定されないなら、リレーエー
ジェントはリンクアドレスフィールドによって識別されたリンク上にメッセー
ジを中継します。
20.3. Construction of Relay-reply Messages
20.3. リレー応答メッセージの生成
A server uses a Relay-reply message to return a response to a client
if the original message from the client was relayed to the server in
a Relay-forward message or to send a Reconfigure message to a client
if the server does not have an address it can use to send the message
directly to the client.
もしクライアントからの元のメッセージがリレー転送メッセージでサーバに
伝えられたなら、あるいは、もしサーバが直接クライアントにメッセージを
送るために使うことができるアドレスを持っていないなら、サーバがクライ
アントに回答を返すか、クライアントに再設定メッセージを送るためリレー
応答メッセージを使います。
A response to the client MUST be relayed through the same relay
agents as the original client message. The server causes this to
happen by creating a Relay-reply message that includes a Relay
Message option containing the message for the next relay agent in the
return path to the client. The contained Relay-reply message
contains another Relay Message option to be sent to the next relay
agent, and so on. The server must record the contents of the
peer-address fields in the received message so it can construct the
appropriate Relay-reply message carrying the response from the
server.
クライアントに対する回答が元のクライアントメッセージと同じリレーエー
ジェントを通して中継されなくてはなりません(MUST)。サーバはクライアン
トへの返送パスの次のリレーエージェントのメッセージを含んでいるリレー
メッセージオプションを含むリレー応答メッセージを作ることによってこれ
を起こさせます。含まれるリレー応答メッセージは次のリレーのエージェン
トに送られるもう１つのリレーメッセージオプションなどを含んでいます。
サーバからの回答を載せた適切なリレー応答メッセージを組み立てることが
できるように、サーバは受信メッセージで相手アドレスフィールドの内容を
記録しなくてはなりません。
For example, if client C sent a message that was relayed by relay
agent A to relay agent B and then to the server, the server would
send the following Relay-Reply message to relay agent B:
例えば、もしクライアントＣがメッセージを送り、これはリレーエージェン
トＡからリレーエージェントＢに中継され、次にサーバに中継されるなら、
サーバじゃ次のリレー応答メッセージをリレーエージェントＢに送るでしょ
う：
msg-type: RELAY-REPLY
hop-count: 1
link-address: 0
peer-address: A
Relay Message option, containing:
msg-type: RELAY-REPLY
hop-count: 0
link-address: address from link to which C is attached
peer-address: C
Relay Message option: <response from server>
訳注：こんなイメージ
+------------------------------------------+
| |---------------------------+ |
| エージェン | エージェン +------------+ | |
| トＢへの | トＡへの | Ｃへの応答 | | |
| リレー応答 | リレー応答 | メッセージ | | |
| メッセージ | メッセージ +------------+ | |
| |---------------------------+ |
+------------------------------------------+
When sending a Reconfigure message to a client through a relay agent,
the server creates a Relay-reply message that includes a Relay
Message option containing the Reconfigure message for the next relay
agent in the return path to the client. The server sets the
peer-address field in the Relay-reply message header to the address
of the client, and sets the link-address field as required by the
relay agent to relay the Reconfigure message to the client. The
server obtains the addresses of the client and the relay agent
through prior interaction with the client or through some external
mechanism.
リレーエージェントを通してクライアントに再設定メッセージを送る時、サー
バはクライアントに返すパスでの次のリレーエージェントのために再設定メッ
セージを含んでいるリレーメッセージオプションを含むリレー応答メッセー
ジを作ります。サーバはリレー応答メッセージヘッダでの相手アドレスフィー
ルドをクライアントのアドレスに設定して、そしてリレーエージェントがク
ライアントに再設定メッセージを伝えるように要求するため、リンクアドレ
スフィールドを設定します。サーバはクライアントとあるいはいずれかの外
部のメカニズムを通しての事前の対話を通してクライアントとリレーエージェ
ントのアドレスを得ます。
21. Authentication of DHCP Messages
21. ＤＨＣＰメッセージ認証
Some network administrators may wish to provide authentication of the
source and contents of DHCP messages. For example, clients may be
subject to denial of service attacks through the use of bogus DHCP
servers, or may simply be misconfigured due to unintentionally
instantiated DHCP servers. Network administrators may wish to
constrain the allocation of addresses to authorized hosts to avoid
denial of service attacks in "hostile" environments where the network
medium is not physically secured, such as wireless networks or
college residence halls.
あるネットワーク管理者がＤＨＣＰメッセージのソースと中身の認証を供給
することを望むかもしれません。例えば、クライアントはにせのＤＨＣＰサー
バによるサービス妨害攻撃の適用を受けているかもしれないし、あるいはた
だ何気なく設置されたＤＨＣＰサーバのために設定誤りになるかもしれませ
ん。無線ネットワークや大学寮ホールのようなネットワークメディアが物理
的に安全に保たれない「敵対的」環境で、ネットワーク管理者がサービス妨
害攻撃を避けるためにアドレス割当を認証されたホストに限定することを望
むかもしれません。
The DHCP authentication mechanism is based on the design of
authentication for DHCPv4 [4].
ＤＨＣＰ認証機構はＤＨＣＰｖ４[4]の認証のデザインに基づいています。
21.1. Security of Messages Sent Between Servers and Relay Agents
21.1. サーバとリレーエージェント間で送られるメッセージのセキュリティ
Relay agents and servers that exchange messages securely use the
IPsec mechanisms for IPv6 [7]. If a client message is relayed
through multiple relay agents, each of the relay agents must have
established independent, pairwise trust relationships. That is, if
messages from client C will be relayed by relay agent A to relay
agent B and then to the server, relay agents A and B must be
configured to use IPSec for the messages they exchange, and relay
agent B and the server must be configured to use IPSec for the
messages they exchange.
安全にメッセージを交換するリレーエージェントとサーバーがＩＰｖ６のＩ
Ｐｓｅｃメカニズムを使います[7]。もしクライアントメッセージが多数のリ
レーエージェントを通して中継されるなら、リレーのエージェントのそれぞ
れが独立に、区間毎の信頼関係の認証をしたに違いありません。すなわち、
もしクライアントＣからのメッセージがリレーエージェントＡとリレーエー
ジェントＢで中継され次にサーバ届くなら、リレーエージェントＡとＢがメッ
セージ交換にＩＰｓｅｃを使うように設定されならならず、そしてリレーエー
ジェントＢとサーバはメッセージ交換にＩＰｓｅｃを使う様に設定されなく
てはなりません。
Relay agents and servers that support secure relay agent to server or
relay agent to relay agent communication use IPsec under the
following conditions:
リレーエージェントとサーバ間あるいはリレーエージェントとリレーエージェ
ント間の安全な通信をサポートするリレーエージェントとサーバは次の状態
でＩＰｓｅｃを使います：
Selectors Relay agents are manually configured with the
addresses of the relay agent or server to which
DHCP messages are to be forwarded. Each relay
agent and server that will be using IPsec for
securing DHCP messages must also be configured
with a list of the relay agents to which messages
will be returned. The selectors for the relay
agents and servers will be the pairs of addresses
defining relay agents and servers that exchange
DHCP messages on the DHCPv6 UDP ports 546 and
547.
セレクター リレーエージェントがＤＨＣＰメッセージが転送され
るはずであるリレーエージェントあるいはサーバーの
アドレスで手設定されます。ＩＰｓｅｃをＤＨＣＰメッ
セージの安全に使っているそれぞれのリレーエージェ
ントとサーバは、メッセージを返すリレーエージェン
トのリストで設定されなくてはなりません。リレーエー
ジェントとサーバのセレクターは、ＤＨＣＰｖ６
ＵＤＰポート５４６と５４７上でＤＨＣＰメッセージ
を交換するリレーエージェントとサーバを定義する対
のアドレスであるでしょう。
Mode Relay agents and servers use transport mode and
ESP. The information in DHCP messages is not
generally considered confidential, so encryption
need not be used (i.e., NULL encryption can be
used).
モード リレーエージェントとサーバーが輸送モードＥＳＰを
使います。ＤＨＣＰメッセージの情報は一般に秘密で
あると思われないので、暗号化が使われる必要があり
ません（すなわち、ヌル暗号を使うことができます）。
Key management Because the relay agents and servers are used
within an organization, public key schemes are
not necessary. Because the relay agents and
servers must be manually configured, manually
configured key management may suffice, but does
not provide defense against replayed messages.
Accordingly, IKE with preshared secrets SHOULD be
supported. IKE with public keys MAY be
supported.
鍵管理 リレーエージェントとサーバが組織の中で使われるの
で、公開鍵は必要ではありません。リレーエージェン
トとサーバが手作業で構成を設定されなくてはならな
いから、手作業で配置された鍵管理で十分であるかも
しれませんが、再生メッセージに対する防衛を供給し
ません。したがって、事前共有秘密鍵のＩＫＥがサポー
トされるべきです(SHOULD)。公開鍵のＩＫＥがサポー
トされるかもしれません(MAY)。
Security policy DHCP messages between relay agents and servers
should only be accepted from DHCP peers as
identified in the local configuration.
セキュリティポリシー リレーエージェントとサーバ間のＤＨＣＰメッ
セージが、ローカル設定で識別されるＤＨＣＰの相手
からだけ受け入れられるだけであるべきです。
Authentication Shared keys, indexed to the source IP address of
the received DHCP message, are adequate in this
application.
認証 共有鍵は、受信ＤＨＣＰメッセージのソースＩＰアド
レスで識別され、アプリケーションに適切です。
Availability Appropriate IPsec implementations are likely to
be available for servers and for relay agents in
more featureful devices used in enterprise and
core ISP networks. IPsec is less likely to be
available for relay agents in low end devices
primarily used in the home or small office
markets.
利用可能性 適切なＩＰｓｅｃ実装は、、企業とコアＩＳＰネット
ワークで使う装置で使う高機能のサーバとリレーエー
ジェントでの利用可能な可能性が高いです。ＩＰｓｅ
ｃはホームや小オフィスの市場で主に使われる低レベ
ル装置でのリレーエージェントに利用可能である可能
性は低いです。
21.2. Summary of DHCP Authentication
21.2. ＤＨＣＰ認証の要約
Authentication of DHCP messages is accomplished through the use of
the Authentication option (see section 22.11). The authentication
information carried in the Authentication option can be used to
reliably identify the source of a DHCP message and to confirm that
the contents of the DHCP message have not been tampered with.
ＤＨＣＰメッセージの認証が認証オプションの使用を通して達成されます
（２２.１１章参照）。認証オプションで運ばれる認証情報は信頼できるよう
にＤＨＣＰメッセージの発信源を識別し、ＤＨＣＰメッセージの中身が不法
に変更されなかったことを確認するために使うことができます。
The Authentication option provides a framework for multiple
authentication protocols. Two such protocols are defined here.
Other protocols defined in the future will be specified in separate
documents.
認証オプションは多数の認証プロトコルに枠組みを提供します。２つのプロ
トコルがここで定義されます。将来定義される他のプロトコルが別の文書で
指定されるでしょう。
Any DHCP message MUST NOT include more than one Authentication
option.
ＤＨＣＰメッセージが１つ以上の認証オプションを含んではなりません
(MUST NOT)。
The protocol field in the Authentication option identifies the
specific protocol used to generate the authentication information
carried in the option. The algorithm field identifies a specific
algorithm within the authentication protocol; for example, the
algorithm field specifies the hash algorithm used to generate the
message authentication code (MAC) in the authentication option. The
replay detection method (RDM) field specifies the type of replay
detection used in the replay detection field.
認証オプションでのプロトコルフィールドは、オプションで運んだ認証情報
を生成するために使われた特定のプロトコルを識別します。アルゴリズム
フィールドは認証プロトコルの中で特定のアルゴリズムを識別します；例え
ば、アルゴリズムフィールドは認証オプションのメッセージ認証コード（Ｍ
ＡＣ）を生成するために使われたハッシュアルゴリズムを指定します。再生
発見方法（ＲＤＭ）フィールドは再生発見フィールドで使われた再生攻撃を
発見する種別を指定します。
21.3. Replay Detection
21.3. 再生攻撃発見
The Replay Detection Method (RDM) field determines the type of replay
detection used in the Replay Detection field.
再生発見方法（ＲＤＭ）フィールドは再生発見フィールドで使われた再生攻
撃の発見の種別を決定します。
If the RDM field contains 0x00, the replay detection field MUST be
set to the value of a monotonically increasing counter. Using a
counter value, such as the current time of day (for example, an NTP-
format timestamp [9]), can reduce the danger of replay attacks. This
method MUST be supported by all protocols.
もしＲＤＭフィールドの値が０x００なら、再生発見フィールドは一様に増加
するカウンター値が設定されなくてはなりません(MUST)。現在の時刻のよう
なカウンター値（例えば、ＮＴＰフォーマット時刻スタンプ[9]）を使うこと
は再生攻撃の危険を減らすことができます。この方法はすべてのプロトコル
でサポート支援されなくてはなりません(MUST)。
21.4. Delayed Authentication Protocol
21.4. 遅延認証プロトコル
If the protocol field is 2, the message is using the "delayed
authentication" mechanism. In delayed authentication, the client
requests authentication in its Solicit message, and the server
replies with an Advertise message that includes authentication
information. This authentication information contains a nonce value
generated by the source as a message authentication code (MAC) to
provide message authentication and entity authentication.
もしプロトコルフィールドが２であるなら、メッセージは「遅延認証」メカ
ニズムを使っています。遅延認証で、クライアントはその要請メッセージで
認証を求め、そしてサーバは認証情報を含む広告メッセージで応えます。こ
の認証情報はメッセージ認証とエンティティー認証を供給するためにメッセー
ジ認証コード（MAC）としてソースによって生成された一時的な値を含んでい
ます。
The use of a particular technique based on the HMAC protocol [8]
using the MD5 hash [16] is defined here.
ＭＤ５ハッシュ[16]を使うＨＭＡＣプロトコル[8]に基づく特定の技法の使用
法はここで定義されます。
21.4.1. Use of the Authentication Option in the Delayed Authentication
Protocol
21.4.1. 遅延認証プロトコルでの認証オプションの使用法
In a Solicit message, the client fills in the protocol, algorithm and
RDM fields in the Authentication option with the client's
preferences. The client sets the replay detection field to zero and
omits the authentication information field. The client sets the
option-len field to 11.
要請メッセージで、クライアントはクライアントの好みで認証オプションの
プロトコルとアルゴリズムとＲＭＤフィールドを記入します。クライアント
は再生発見フィールドにゼロに設定し、認証情報フィールドを省略します。
クライアントはオプション長フィールドを１１に設定します。
In all other messages, the protocol and algorithm fields identify the
method used to construct the contents of the authentication
information field. The RDM field identifies the method used to
construct the contents of the replay detection field.
すべての他のメッセージで、プロトコルとアルゴリズムフィールドは認証情
報フィールドの内容を組み立てるのに使われた方法を識別します。ＲＭＤ
フィールドは再生発見フィールドの内容を組み立てる使われた方法を識別し
ます。
The format of the Authentication information is:
認証情報のフォーマットは以下です：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP realm |
| (variable length) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC-MD5 |
| (128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DHCP realm The DHCP realm that identifies the key used to
generate the HMAC-MD5 value.
ＨＭＡＣ−ＭＤ５値を生成するために使われた鍵を識別する
ＤＨＣＰ領域。
key ID The key identifier that identified the key used to
generate the HMAC-MD5 value.
ＨＭＡＣ−ＭＤ５値を生み出した鍵を識別するために使われ
る鍵識別子。
HMAC-MD5 The message authentication code generated by applying
MD5 to the DHCP message using the key identified by
the DHCP realm, client DUID, and key ID.
ＭＤ５で，ＤＨＣＰ領域よクライアントＤＵＩＤと鍵識別子
で識別された鍵を、ＤＨＣＰメッセージに適用して生成され
た、メッセージ認証コード。
The sender computes the MAC using the HMAC generation algorithm [8]
and the MD5 hash function [16]. The entire DHCP message (setting the
MAC field of the authentication option to zero), including the DHCP
message header and the options field, is used as input to the HMAC-
MD5 computation function.
送信者はＨＭＡＣ生成アルゴリズム[8]とＭＤ５ハッシュ関数[16]を使ってＭ
ＡＣを計算します。（認証オプションのＭＡＣフィールドをゼロに設定して
いる）全部のＤＨＣＰメッセージは、ＤＨＣＰメッセージヘッダとオプショ
ンフィールドを含めて、ＨＭＡＣ−ＭＤ５計算関数への入力として用いられ
ます。
DISCUSSION:
論議：
Algorithm 1 specifies the use of HMAC-MD5. Use of a different
technique, such as HMAC-SHA, will be specified as a separate
protocol.
アルゴリズム１がＨＭＡＣ−ＭＤ５の使用を指定します。ＨＭＡＣ−ＳＨ
Ａのような、異なった技法の使用は別のプロトコルとして明示されるでしょ
う。
The DHCP realm used to identify authentication keys is chosen to
be unique among administrative domains. Use of the DHCP realm
allows DHCP administrators to avoid conflict in the use of key
identifiers, and allows a host using DHCP to use authenticated
DHCP while roaming among DHCP administrative domains.
認証鍵を識別するために使われたＤＨＣＰ領域は管理ドメイン間で一意に
なるように選ばれます。ＤＨＣＰ領域の使用は鍵識別子の使用でＤＨＣＰ
管理者の対立を避けることを許し、そしてＤＨＣＰを使うホストが、ＤＨ
ＣＰ間で管理ドメインを歩き回る間に、本物と証明されたＤＨＣＰを使う
ことを許します。
21.4.2. Message Validation
21.4.2. メッセージ検証
Any DHCP message that includes more than one authentication option
MUST be discarded.
２つ以上の認証オプションを含むＤＨＣＰメッセージは捨てられなくてはな
りません(MUST)。
To validate an incoming message, the receiver first checks that the
value in the replay detection field is acceptable according to the
replay detection method specified by the RDM field. Next, the
receiver computes the MAC as described in [8]. The entire DHCP
message (setting the MAC field of the authentication option to 0) is
used as input to the HMAC-MD5 computation function. If the MAC
computed by the receiver does not match the MAC contained in the
authentication option, the receiver MUST discard the DHCP message.
入りメッセージを有効にするために、受信者は最初に再生発見フィールドの
中の値が、ＲＤＭフィールドによって指定される再生発見方法で、許容でき
るかを調べます。次に、受信者は、[8]で記述されるように、ＭＡＣを計算
します。（認証オプションのＭＡＣフィールドを０に設定している）全部の
ＤＨＣＰメッセージは、ＨＭＡＣ−ＭＤ５計算関数の入力として用いられま
す。もし受信者が計算したＭＡＣが認証オプションに含まれるＭＡＣと一致
しないなら、受信者はＤＨＣＰメッセージを捨てなくてはなりません(MUST)。
21.4.3. Key Utilization
21.4.3. 鍵使用
Each DHCP client has a set of keys. Each key is identified by <DHCP
realm, client DUID, key id>. Each key also has a lifetime. The key
may not be used past the end of its lifetime. The client's keys are
initially distributed to the client through some out-of-band
mechanism. The lifetime for each key is distributed with the key.
Mechanisms for key distribution and lifetime specification are beyond
the scope of this document.
それぞれのＤＨＣＰクライアントが鍵集合を持っています。それぞれの鍵が
＜ＤＨＣＰ領域、クライアントＤＵＩＤ、鍵識別子＞で識別されます。それ
ぞれの鍵が同じく寿命を持ちます。鍵はその寿命の終わりを過ぎたら使われ
ないかもしれません。クライアントの鍵は何らかの外部メカニズムを通して
初めにクライアントに配られます。それぞれの鍵のための寿命は鍵と共に配
られます。鍵配布と寿命仕様のメカニズムはこの文書の範囲外です。
The client and server use one of the client's keys to authenticate
DHCP messages during a session (until the next Solicit message sent
by the client).
クライアントとサーバは（クライアントが次の要請メッセージを送信するま
で）セッションの間にＤＨＣＰメッセージを本物と証明するためにクライア
ントの鍵の１つを使います。
21.4.4. Client Considerations for Delayed Authentication Protocol
21.4.4. 遅延認証プロトコルに対するクライアント考慮
The client announces its intention to use DHCP authentication by
including an Authentication option in its Solicit message. The
server selects a key for the client based on the client's DUID. The
client and server use that key to authenticate all DHCP messages
exchanged during the session.
クライアントは要請メッセージに認証オプションを含めることによってＤＨ
ＣＰ認証を使う意向を示します。サーバはクライアントのＤＵＩＤに基づい
てクライアントの鍵を選択します。クライアントとサーバはすべてのセッショ
ンの間に交換されたＤＨＣＰメッセージを本物と証明するためにその鍵を使
います。
21.4.4.1. Sending Solicit Messages
21.4.4.1. 要請メッセージ送信
When the client sends a Solicit message and wishes to use
authentication, it includes an Authentication option with the desired
protocol, algorithm and RDM as described in section 21.4. The client
does not include any replay detection or authentication information
in the Authentication option.
クライアントが要請メッセージを送り、認証を使うことを望む時、２１.４章
で記述された望ましいプロトコルとアルゴリズムとＲＭＤを含む認証オプショ
ンを含めます。クライアントは認証オプションに再生発見あるいは認証情報
を含めません。
21.4.4.2. Receiving Advertise Messages
21.4.4.2. 広告メッセージ受信
The client validates any Advertise messages containing an
Authentication option specifying the delayed authentication protocol
using the validation test described in section 21.4.2.
クライアントは２１.４.２章で記述した検証テストを使って、遅延認証プロ
トコルを指定する認証オプションを含んでいる広告メッセージを検証します。
Client behavior, if no Advertise messages include authentication
information or pass the validation test, is controlled by local
policy on the client. According to client policy, the client MAY
choose to respond to an Advertise message that has not been
authenticated.
広告メッセージが認証情報を含まないか、あるいは承認テストに合格する場
合の、クライアント動作はクライアントのローカルポリシーによって制御さ
れます。クライアントポリシーによっては、クライアントは本物と証明され
なかった広告メッセージに返答することに決めてもよいです(MAY)。
The decision to set local policy to accept unauthenticated messages
should be made with care. Accepting an unauthenticated Advertise
message can make the client vulnerable to spoofing and other attacks.
If local users are not explicitly informed that the client has
accepted an unauthenticated Advertise message, the users may
incorrectly assume that the client has received an authenticated
address and is not subject to DHCP attacks through unauthenticated
messages.
ローカルポリシーで本物と証明されていないメッセージを受け入れることに
定める決断は注意してされるべきです。本物と証明されていない広告メッセー
ジを受け入れると、クライアントはなりすましと他の攻撃に傷つきやすくな
ります。もしローカルなユーザが明示的にクライアントが本物と証明されて
いない広告メッセージ受け入れたということを知らせられないなら、ユーザ
は間違ってクライアントが本物と証明されたアドレスを受け取り、そして本
物と証明されていないメッセージを通してＤＨＣＰ攻撃の適用を受けていな
いと想定してもよいです。
A client MUST be configurable to discard unauthenticated messages,
and SHOULD be configured by default to discard unauthenticated
messages if the client has been configured with an authentication key
or other authentication information. A client MAY choose to
differentiate between Advertise messages with no authentication
information and Advertise messages that do not pass the validation
test; for example, a client might accept the former and discard the
latter. If a client does accept an unauthenticated message, the
client SHOULD inform any local users and SHOULD log the event.
クライアントが本物と証明されていないメッセージを捨てる設定が可能であ
るに違いなくて(MUST)、そしてデフォルトで、もしクライアントが認証鍵や
他の認証情報で構成を設定されたなら、本物と証明されていないメッセージ
を捨てるように設定されるべきです(SHOULD)。クライアントが認証情報がな
い広告メッセージと承認テストに合格しない広告メッセージをを区別するこ
とに決めてもよいです(MAY)；例えば、クライアントが前者を受け入れて、
そして後者を捨てるかもしれません。もしクライアントが本物と証明されて
いないメッセージを受け入れるなら、クライアントはローカルユーザに知ら
せるべきであって(SHOULD)、そしてイベントをログファイルに書くべきです
(SHOULD)。
21.4.4.3. Sending Request, Confirm, Renew, Rebind, Decline or Release
Messages
21.4.4.3. 要求、確証、更新、再結合、辞退、開放メッセージの送信
If the client authenticated the Advertise message through which the
client selected the server, the client MUST generate authentication
information for subsequent Request, Confirm, Renew, Rebind or Release
messages sent to the server, as described in section 21.4. When the
client sends a subsequent message, it MUST use the same key used by
the server to generate the authentication information.
もしクライアントが選んだサーバの広告メッセージをクライアントが本物と
証明したなら、クライアントはサーバへ送る次の要求か確証か更新か再結合
か辞退か開放メッセージのために、２１.４で記述されるように、認証情報
を生成しなくてはなりません(MUST)。クライアントが次のメッセージを送る
時、認証情報を生み出すためにサーバによって使われたのと同じ鍵を使わな
くてはなりません(MUST)。
21.4.4.4. Sending Information-request Messages
21.4.4.4. 情報要求メッセージ送信
If the server has selected a key for the client in a previous message
exchange (see section 21.4.5.1), the client MUST use the same key to
generate the authentication information throughout the session.
もしサーバが前のメッセージ交換でクライアントの鍵を選択したなら
（２１.４.５.１章参照）、クライアントはセッションを通じて認証情報を生
成するために同じ鍵を使わなくてはなりません(MUST)。
21.4.4.5. Receiving Reply Messages
21.4.4.5. 応答メッセージ受信
If the client authenticated the Advertise it accepted, the client
MUST validate the associated Reply message from the server. The
client MUST discard the Reply if the message fails to pass the
validation test and MAY log the validation failure. If the Reply
fails to pass the validation test, the client MUST restart the DHCP
configuration process by sending a Solicit message.
もしクライアントが受信した広告を認証したなら、クライアントはサーバか
らの関連した応答メッセージを有効にしなくてはなりません(MUST)。もしメッ
セージが検証試験に失敗したらクライアントは応答を捨てなければならず
(MUST)、そして検証失敗をログファイルに書いてもよいです(MAY)。もし応答
が検証試験に失敗するなら、クライアントは要請メッセージを送ることによっ
てＤＨＣＰ設定処理を再開しなくてはなりません(MUST)。
If the client accepted an Advertise message that did not include
authentication information or did not pass the validation test, the
client MAY accept an unauthenticated Reply message from the server.
もしクライアントが認証情報を含まない広告メッセージを受信するか、ある
いは検証試験に合格しなかったなら、クライアントはサーバからの本物と証
明されていない応答メッセージを受け入れてもよいです(MAY)。
21.4.4.6. Receiving Reconfigure Messages
21.4.4.6. 再設定メッセージ受信
The client MUST discard the Reconfigure if the message fails to pass
the validation test and MAY log the validation failure.
クライアントは、もしメッセージが認証試験に失敗したら再設定メッセージ
を捨てなくてはなりません(MUST)、そして認証失敗をログファイルに書いて
もよいです(MAY)。
21.4.5. Server Considerations for Delayed Authentication Protocol
21.4.5. 遅延認証プロトコルに対するサーバの考慮
After receiving a Solicit message that contains an Authentication
option, the server selects a key for the client, based on the
client's DUID and key selection policies with which the server has
been configured. The server identifies the selected key in the
Advertise message and uses the key to validate subsequent messages
between the client and the server.
認証オプションを含んでいる要請メッセージを受け取った後で、サーバはク
ライアントのＤＵＩＤと鍵選択ポリシーに基づいて、サーバに設定されたク
ライアントの鍵を選択します。サーバは広告メッセージで選択された鍵を識
別し、そしてクライアントとサーバの間の次のメッセージを有効にするため
に鍵を使います。
21.4.5.1. Receiving Solicit Messages and Sending Advertise Messages
21.4.5.1. 要請メッセージ受信と広告メッセージ送信
The server selects a key for the client and includes authentication
information in the Advertise message returned to the client as
specified in section 21.4. The server MUST record the identifier of
the key selected for the client and use that same key for validating
subsequent messages with the client.
サーバはクライアントのために鍵を選択して、２１.４章で指定されるように、
クライアントに返す広告メッセージに認証情報を含めます。サーバはクライ
アントのために選択した鍵の識別子を記録し(MUST)、同じ鍵をクライアント
との続くメッセージの検証に使います。
21.4.5.2. Receiving Request, Confirm, Renew, Rebind or Release Messages
and Sending Reply Messages
21.4.5.2. 要求と確証と更新と再結合と開放メッセージの受信と応答メッセージの送信
The server uses the key identified in the message and validates the
message as specified in section 21.4.2. If the message fails to pass
the validation test or the server does not know the key identified by
the 'key ID' field, the server MUST discard the message and MAY
choose to log the validation failure.
サーバは２１.４.２章で指定されるようにメッセージで識別鍵を使い、そし
てメッセージを有効にします。もしメッセージが認証試験に失敗するか、あ
るいはサーバが「鍵識別子（ＩＤ）」フィールドで識別された鍵を知らない
なら、サーバはメッセージを捨てなくてはならなくて(MUST)、そして認証障
害をログファイルに書くことに決めてもよいです(MAY)。
If the message passes the validation test, the server responds to the
specific message as described in section 18.2. The server MUST
include authentication information generated using the key identified
in the received message, as specified in section 21.4.
もしメッセージが認証試験に合格するなら、１８.２章で記述されるように、
サーバは特定のメッセージで返答します。２１.４章で指定されるように、サー
バは鍵を使って生成された認証情報を、受信メッセージに含めなくてはなり
ません(MUST)。
21.5. Reconfigure Key Authentication Protocol
21.5. 再設定鍵認証プロトコル
The Reconfigure key authentication protocol provides protection
against misconfiguration of a client caused by a Reconfigure message
sent by a malicious DHCP server. In this protocol, a DHCP server
sends a Reconfigure Key to the client in the initial exchange of DHCP
messages. The client records the Reconfigure Key for use in
authenticating subsequent Reconfigure messages from that server. The
server then includes an HMAC computed from the Reconfigure Key in
subsequent Reconfigure messages.
再設定鍵認証プロトコルは悪意があるＤＨＣＰサーバが送った再設定メッセー
ジによって起こったクライアントの設定誤りに対しての保護を供給します。
このプロトコルで、ＤＨＣＰサーバがＤＨＣＰメッセージの最初の交換でク
ライアントに再設定鍵を送ります。クライアントはそのサーバからの次の再
設定メッセージの確認のために再設定鍵を記録します。サーバは次の再設定
メッセージに再設定鍵から計算されたＨＭＡＣを含めます。
Both the Reconfigure Key sent from the server to the client and the
HMAC in subsequent Reconfigure messages are carried as the
Authentication information in an Authentication option. The format
of the Authentication information is defined in the following
section.
サーバからクライアントに送られた再設定鍵と次の再設定メッセージでＨＭ
ＡＣの両方で認証オプションで認証情報が運ばれます。認証情報のフォーマッ
トは次章で定義されます。
The Reconfigure Key protocol is used (initiated by the server) only
if the client and server are not using any other authentication
protocol and the client and server have negotiated to use Reconfigure
messages.
再設定鍵プロトコルはクライアントとサーバが（サーバによって始められた）
他のいかなる認証プロトコルも使っていない限り使われます、そしてクライ
アントとサーバは再設定メッセージを使うために交渉します。
21.5.1. Use of the Authentication Option in the Reconfigure Key
Authentication Protocol
21.5.1. 再設定鍵認証プロトコルでの認証オプションの使用
The following fields are set in an Authentication option for the
Reconfigure Key Authentication Protocol:
次のフィールドは認証オプションで再設定鍵認証プロトコルを設定します：
protocol 3
algorithm 1
RDM 0
The format of the Authentication information for the Reconfigure Key
Authentication Protocol is:
再設定鍵認証プロトコルのための認証情報のフォーマットは以下です：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Value (128 bits) |
+-+-+-+-+-+-+-+-+ |
. .
. .
. +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type of data in Value field carried in this option:
このオプションが価フィールドで運ぶデータの種別：
1 Reconfigure Key value (used in Reply message).
再設定鍵値（応答メッセージで使用）
2 HMAC-MD5 digest of the message (used in Reconfigure
message).
（再設定メッセージで使われた）メッセージのＨＭＡＣ−
ＭＤ５ダイジェスト。
Value Data as defined by field.
フィールドで定義されたデータ。
21.5.2. Server considerations for Reconfigure Key protocol
21.5.2. 再設定鍵プロトコルに対するサーバの考慮
The server selects a Reconfigure Key for a client during the
Request/Reply, Solicit/Reply or Information-request/Reply message
exchange. The server records the Reconfigure Key and transmits that
key to the client in an Authentication option in the Reply message.
サーバは要求／応答や要請／応答や情報要求／応答メッセージ交換の間にク
ライアントのために再設定鍵を選択します。サーバは再設定鍵を記録して、
そして応答メッセージの認証オプションでクライアントにその鍵を伝達します。
The Reconfigure Key is 128 bits long, and MUST be a cryptographically
strong random or pseudo-random number that cannot easily be
predicted.
再設定鍵は長さ１２８ビットで、そして容易に予言されることができない暗
号的に強い乱数あるいは疑似乱数に違いありません(MUST)。
To provide authentication for a Reconfigure message, the server
selects a replay detection value according to the RDM selected by the
server, and computes an HMAC-MD5 of the Reconfigure message using the
Reconfigure Key for the client. The server computes the HMAC-MD5
over the entire DHCP Reconfigure message, including the
Authentication option; the HMAC-MD5 field in the Authentication
option is set to zero for the HMAC-MD5 computation. The server
includes the HMAC-MD5 in the authentication information field in an
Authentication option included in the Reconfigure message sent to the
client.
再設定メッセージの認証を提供するために、サーバが選択するＲＤＭに従っ
て、サーバは再生発見値を選択して、そしてクライアントの再設定鍵を使っ
て再設定メッセージのＨＭＡＣ−ＭＤ５を計算します。サーバは全部のＤＨ
ＣＰ再設定メッセージ上で、認証オプションを含めてＨＭＡＣ−ＭＤ５を計
算します；認証オプションでのＨＭＡＣ−ＭＤ５フィールドはＨＭＡＣ−Ｍ
Ｄ５計算の際にはゼロに設定されます。サーバはクライアントに送った再設
定メッセージに含められた認証オプションの認証情報フィールドにＨＭＡＣ−
ＭＤ５を含めます。
21.5.3. Client considerations for Reconfigure Key protocol
21.5.3. 再設定鍵プロトコルに対するクライアントの考慮
The client will receive a Reconfigure Key from the server in the
initial Reply message from the server. The client records the
Reconfigure Key for use in authenticating subsequent Reconfigure
messages.
クライアントはサーバからの最初の応答メッセージで再設定鍵を受け取るで
しょう。クライアントは次の再設定メッセージを本物と証明する際に使用す
るために再設定鍵を記録します
To authenticate a Reconfigure message, the client computes an
HMAC-MD5 over the DHCP Reconfigure message, using the Reconfigure Key
received from the server. If this computed HMAC-MD5 matches the
value in the Authentication option, the client accepts the
Reconfigure message.
再設定メッセージを本物と証明するために、クライアントはサーバから受け
取った再設定鍵を使っているＤＨＣＰ再設定メッセージ上のＨＭＡＣ−ＭＤ
５を計算します。もしＨＭＡＣ−ＭＤ５が認証オプション値に一致すると計
算したなら、クライアントは再設定メッセージを受け入れます。
22. DHCP Options
22. ＤＨＣＰオプション
Options are used to carry additional information and parameters in
DHCP messages. Every option shares a common base format, as
described in section 22.1. All values in options are represented in
network byte order.
オプションがＤＨＣＰメッセージで追加情報とパラメータを運ぶために使わ
れます。すべてのオプションが、２２.１章で記述されるように、基本フォー
マットを共有します。すべてのオプションの値はネットワークバイト順で表
されます。
This document describes the DHCP options defined as part of the base
DHCP specification. Other options may be defined in the future in
separate documents.
この文書は基本ＤＨＣＰ仕様書の一部と定義されたＤＨＣＰオプションを記
述します。他のオプションが別の文書で将来定義されるかもしれません。
Unless otherwise noted, each option may appear only in the options
area of a DHCP message and may appear only once. If an option does
appear multiple times, each instance is considered separate and the
data areas of the options MUST NOT be concatenated or otherwise
combined.
特に記載していなければ、各オプションはＤＨＣＰメッセージのオプション
エリアにだけ存在するかもしれず、そしてただ１度だけ存在するかもしれま
せん。もしオプションが何度も現れるなら、各オプションが異なると考えら
れ、そしてオプションのデータエリアを連結したり混ぜたりしてはなりませ
ん(MUST NOT)。
22.1. Format of DHCP Options
22.1. ＤＨＣＰオプションのフォーマット
The format of DHCP options is:
ＤＨＣＰオプションのフォーマットは以下です：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-data |
| (option-len octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code An unsigned integer identifying the specific option
type carried in this option.
このオプションに設定するオプション種別を識別する符号
なし整数。
option-len An unsigned integer giving the length of the
option-data field in this option in octets.
このオプションのオプションデータフィールドのオクテッ
ト単位の長さを与える符号なし整数。
option-data The data for the option; the format of this data
depends on the definition of the option.
このオプションのデータ；データフォーマットはオプショ
ンの定義に依存します。
DHCPv6 options are scoped by using encapsulation. Some options apply
generally to the client, some are specific to an IA, and some are
specific to the addresses within an IA. These latter two cases are
discussed in sections 22.4 and 22.6.
ＤＨＣＰｖ６オプションがカプセル化を使うことによって有効範囲を指定さ
れます。あるオプションがクライアントに一般的に当てはまり、いくつかは
ＩＡ固有で、いくつかがＩＡのアドレスに固有です。後の２つの場合は
２２.４章と２２.６章で論じられます。
22.2. Client Identifier Option
22.2. クライアント識別子オプション
The Client Identifier option is used to carry a DUID (see section 9)
identifying a client between a client and a server. The format of
the Client Identifier option is:
クライアント識別子オプションはクライアントとサーバの間で、クライアン
トを識別するＤＵＩＤを運ぶために使われます（９章参照）。クライアント
識別子オプションのフォーマットは以下です：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CLIENTID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. DUID .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CLIENTID (1).
option-len Length of DUID in octets.
オクテット単位のＤＵＩＤの長さ
DUID The DUID for the client.
クライアントのＤＵＩＤ
22.3. Server Identifier Option
22.3. サーバ識別子オプション
The Server Identifier option is used to carry a DUID (see section 9)
identifying a server between a client and a server. The format of
the Server Identifier option is:
サーバ識別子オプションは、クライアントとサーバの間でサーバを識別する
ＤＵＩＤを運ぶために使われます（９章参照）。サーバ識別子オプションの
フォーマットは以下です：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SERVERID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. DUID .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_SERVERID (2).
option-len Length of DUID in octets.
オクテット単位のＤＵＩＤの長さ
DUID The DUID for the server.
サーバのＤＵＩＤ
22.4. Identity Association for Non-temporary Addresses Option
22.4. 非臨時アドレス識別子集団オプション
The Identity Association for Non-temporary Addresses option (IA_NA
option) is used to carry an IA_NA, the parameters associated with the
IA_NA, and the non-temporary addresses associated with the IA_NA.
非臨時アドレス識別子集団オプション（ＩＡ＿ＮＡオプション）のはＩＡ＿
ＮＡとＩＡ＿ＮＡに関連するパラメータとＩＡ＿ＮＡに関連する非臨時アド
レスとを運ぶために使われます。
Addresses appearing in an IA_NA option are not temporary addresses
(see section 22.5).
ＩＡ＿ＮＡオプションに現われるアドレスは一時的なアドレスではありませ
ん（２２.５章参照）。
The format of the IA_NA option is:
ＩＡ＿ＮＡオプションのフォーマットは以下です：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IA_NA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. IA_NA-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_IA_NA (3).
option-len 12 + length of IA_NA-options field.
１２＋ＩＡ＿ＮＡオプションフィールドの長さ
IAID The unique identifier for this IA_NA; the
IAID must be unique among the identifiers for
all of this client's IA_NAs. The number
space for IA_NA IAIDs is separate from the
number space for IA_TA IAIDs.
このＩＡ＿ＮＡの一意な識別子；ＩＡＩＤはすべ
てのクライアントのＩＡ＿ＮＡの識別子の間で一
意に違いありません。ＩＡ＿ＮＡ ＩＡＩＤのの番
号空間はＩＡ＿ＴＡ ＩＡＩＤの番号空間から独立
しています。
T1 The time at which the client contacts the
server from which the addresses in the IA_NA
were obtained to extend the lifetimes of the
addresses assigned to the IA_NA; T1 is a
time duration relative to the current time
expressed in units of seconds.
ＩＡ＿ＮＡに割当てられた寿命を延長するために、
クライアントがＩＡ＿ＮＡに割り当てられたアド
レスを得たサーバに連絡を取る時間；Ｔ１が現在
の時刻からの秒単位で表現されたの時間間隔です。
T2 The time at which the client contacts any
available server to extend the lifetimes of
the addresses assigned to the IA_NA; T2 is a
time duration relative to the current time
expressed in units of seconds.
クライアントがＩＡ＿ＮＡに割り当てられたアド
レスの寿命を延長するために任意の利用可能なサー
バと連絡を取る時間；Ｔ２が現在の時刻からの秒
単位で表現された時間間隔です。
IA_NA-options Options associated with this IA_NA.
ＩＡ＿ＮＡと関連したオプション
The IA_NA-options field encapsulates those options that are specific
to this IA_NA. For example, all of the IA Address Options carrying
the addresses associated with this IA_NA are in the IA_NA-options
field.
ＩＡ＿ＮＡオプションフィールドはこのＩＡ＿ＮＡに固有のオプションをカ
プセル化します。例えば、このＩＡ＿ＮＡに関連したアドレスをもつＩＡ＿
ＮＡアドレスオプションの全てがオプションフィールドにあります。
An IA_NA option may only appear in the options area of a DHCP
message. A DHCP message may contain multiple IA_NA options.
ＩＡ＿ＮＡオプションがただＤＨＣＰメッセージのオプションエリアに現わ
れるだけかもしれません。ＤＨＣＰメッセージが多数のＩＡ＿ＮＡオプショ
ンを含んでいるかもしれません。
The status of any operations involving this IA_NA is indicated in a
Status Code option in the IA_NA-options field.
このＩＡ＿ＮＡを含むオペレーションの状態は、ＩＡ＿ＮＡオプションの状
態コードオプションで示されます。
Note that an IA_NA has no explicit "lifetime" or "lease length" of
its own. When the valid lifetimes of all of the addresses in an
IA_NA have expired, the IA_NA can be considered as having expired.
T1 and T2 are included to give servers explicit control over when a
client recontacts the server about a specific IA_NA.
ＩＡ＿ＮＡがこれ自身の明示的な「寿命」や「リース期間」を持っていない
ことに注意してください。ＩＡ＿ＮＡのアドレスのすべての正式な寿命の期
限が切れた時、ＩＡ＿ＮＡは期限切れと考ることができます。特定のＩＡ＿
ＮＡについていつクライアントがサーバに通信するかに関して、Ｔ１とＴ２
がサーバの明示的な制御を与えるために含まれます。
In a message sent by a client to a server, values in the T1 and T2
fields indicate the client's preference for those parameters. The
client sets T1 and T2 to 0 if it has no preference for those values.
In a message sent by a server to a client, the client MUST use the
values in the T1 and T2 fields for the T1 and T2 parameters, unless
those values in those fields are 0. The values in the T1 and T2
fields are the number of seconds until T1 and T2.
クライアントからサーバに送られたメッセージで、Ｔ１とＴ２フィールドの
値は、クライアントのこれらのパラメータに対する好みを示します。クライ
アントは、もしこれらの値に対する好みを持っていないなら、Ｔ１とＴ２に
０を設定します。サーバからクライアントに送られたメッセージで、クライ
アントは、フィールドの値が０なければ、Ｔ１とＴ２フィールドの値をＴ１
とＴ２パラメータのために使わなくてはなりません(MUST)。Ｔ１とＴ２フィー
ルドの値は、Ｔ１とＴ２までの秒数です。
The server selects the T1 and T2 times to allow the client to extend
the lifetimes of any addresses in the IA_NA before the lifetimes
expire, even if the server is unavailable for some short period of
time. Recommended values for T1 and T2 are .5 and .8 times the
shortest preferred lifetime of the addresses in the IA that the
server is willing to extend, respectively. If the "shortest"
preferred lifetime is 0xffffffff ("infinity"), the recommended T1 and
T2 values are also 0xffffffff. If the time at which the addresses in
an IA_NA are to be renewed is to be left to the discretion of the
client, the server sets T1 and T2 to 0.
たとえサーバが短期間の間応対できないとしても、クライアントに寿命が切
れる前にＩＡ＿ＮＡのアドレス寿命を伸ばのを許すために、サーバはＴ１と
Ｔ２時間を選びます。Ｔ１とＴ２の推薦された値はサーバが延長をするＩＡ
内のアドレスの最短寿命の、それぞれ．５倍と．８倍です。もし「最短」の
望ましい寿命が0xffffffff（「無限」）であるなら、推薦されたＴ１とＴ２
値は同じく0xffffffffです。もしＩＡ＿ＮＡのアドレスが更新される時刻は、
クライアントが自由に決めれるなら、サーバはＴ１とＴ２を０に設定します。
If a server receives an IA_NA with T1 greater than T2, and both T1
and T2 are greater than 0, the server ignores the invalid values of
T1 and T2 and processes the IA_NA as though the client had set T1 and
T2 to 0.
もしサーバがＴ２より大きいＴ１でＩＡ＿ＮＡを受け取り、そしてＴ１と
Ｔ２の両方が０より大きいなら、サーバは無効なＴ１とＴ２の値を無視して、
クライアントがＴ１とＴ２に０に設定したかのように、ＩＡ＿ＮＡを処理し
ます。
If a client receives an IA_NA with T1 greater than T2, and both T1
and T2 are greater than 0, the client discards the IA_NA option and
processes the remainder of the message as though the server had not
included the invalid IA_NA option.
もしクライアントがＴ２より大きいＴ１でＩＡ＿ＮＡを受け取り、そして
Ｔ１とＴ２の両方が０より大きいなら、クライアントはＩＡ＿ＮＡオプショ
ンを捨てて、サーバが無効なＩＡ＿ＮＡオプションを含まなかったかのよ
うに、メッセージの残りを処理します。
Care should be taken in setting T1 or T2 to 0xffffffff ("infinity").
A client will never attempt to extend the lifetimes of any addresses
in an IA with T1 set to 0xffffffff. A client will never attempt to
use a Rebind message to locate a different server to extend the
lifetimes of any addresses in an IA with T2 set to 0xffffffff.
Ｔ１とＴ２に0xffffffff（「無限」）を設定するには注意が必要です。クラ
イアントが決して0xffffffffを設定したＴ１を持つＩＡのアドレスの寿命の
延長を試みないでしょう。クライアントが0xffffffffを設定したＴ２を持つ
ＩＡのアドレスを延長するために、他のサーバの場所を突き止める再結合メッ
セージを使おうと試みないでしょう。
22.5. Identity Association for Temporary Addresses Option
22.5. 一時的アドレスオプション識別子集団
The Identity Association for the Temporary Addresses (IA_TA) option
is used to carry an IA_TA, the parameters associated with the IA_TA
and the addresses associated with the IA_TA. All of the addresses in
this option are used by the client as temporary addresses, as defined
in RFC 3041 [12]. The format of the IA_TA option is:
一時的アドレス（ＩＡ＿ＴＡ）オプションのための識別子集団はＩＡ＿ＴＡ
とＩＡ＿ＴＡに関連するパラメータとＩＡ＿ＴＡに関連するあどれづを運ぶ
ために使われます。このオプションのアドレスのすべてが、ＲＦＣ３０４１
[12]で定義される一時的なアドレスとして、クライアントによって使われま
す。ＩＡ＿ＴＡオプションのフォーマットは以下です：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IA_TA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. IA_TA-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_IA_TA (4).
option-len 4 + length of IA_TA-options field.
４＋ＩＡ＿ＴＡオプションフィールドの長さ
IAID The unique identifier for this IA_TA; the
IAID must be unique among the identifiers
for all of this client's IA_TAs. The number
space for IA_TA IAIDs is separate from the
number space for IA_NA IAIDs.
このＩＡ＿ＴＡのためのユニークな識別子；ＩＡ
ＩＤはこのクライアントのすべてのＩＡ＿ＴＡの
識別子の中で一意に違いありません。ＩＡ＿ＴＡ
ＩＡＩＤのための番号空間はＩＡ＿ＮＡ ＩＡＩＤ
の番号空間から独立しています。
IA_TA-options Options associated with this IA_TA.
このＩＡ＿ＴＡに関連するオプション
The IA_TA-Options field encapsulates those options that are specific
to this IA_TA. For example, all of the IA Address Options carrying
the addresses associated with this IA_TA are in the IA_TA-options
field.
ＩＡ＿ＴＡオプションフィールドはこのＩＡ＿ＴＡに固有のオプションをま
とめます。例えば、このＩＡ＿ＴＡと関連したアドレスを持つＩＡアドレス
オプションのすべてがＩＡ＿ＴＡオプションフィールドにあります。
Each IA_TA carries one "set" of temporary addresses; that is, at most
one address from each prefix assigned to the link to which the client
is attached.
各ＩＡ＿ＴＡは１つのアドレスの「セット」を運びます；これは、最大1つの
アドレスで、クライアントの接続するリンクに割り当てられたそれぞれのプ
レフィックスです。
An IA_TA option may only appear in the options area of a DHCP
message. A DHCP message may contain multiple IA_TA options.
ＩＡ＿ＴＡオプションがＤＨＣＰメッセージのオプションエリアに現われる
だけかもしれません。ＤＨＣＰメッセージが多数のＩＡ＿ＴＡオプションを
含んでいるかもしれません。
The status of any operations involving this IA_TA is indicated in a
Status Code option in the IA_TA-options field.
このＩＡ＿ＴＡに関連するオプションの状態は、ＩＡ＿ＴＡオプションフィー
ルドの状態コードで示されます。
Note that an IA has no explicit "lifetime" or "lease length" of its
own. When the valid lifetimes of all of the addresses in an IA_TA
have expired, the IA can be considered as having expired.
ＩＡが明示的な「寿命」や「リース期間」を持たないことに注意してくださ
い。ＩＡ＿ＴＡのアドレスのすべての正式な寿命の期限が切れた時、ＩＡは
期限が切れたと考えられます。
An IA_TA option does not include values for T1 and T2. A client MAY
request that the lifetimes on temporary addresses be extended by
including the addresses in a IA_TA option sent in a Renew or Rebind
message to a server. For example, a client would request an
extension on the lifetime of a temporary address to allow an
application to continue to use an established TCP connection.
ＩＡ＿ＴＡオプションがＴ１とＴ２のための値を含みません。ＩＡ＿ＴＡ
プションにアドレスを設定して更新か再結合メッセージでサーバに送るこ
とで、クライアントは一時的アドレスの寿命を延ば事を要求するかもしれ
ません(MAY)。例えば、クライアントがアプリケーションで確立されたＴＣ
Ｐ接続を使い続けることを許すために、一時的なアドレスの寿命の拡張を
求めるでしょう。
The client obtains new temporary addresses by sending an IA_TA option
with a new IAID to a server. Requesting new temporary addresses from
the server is the equivalent of generating new temporary addresses as
described in RFC 3041. The server will generate new temporary
addresses and return them to the client. The client should request
new temporary addresses before the lifetimes on the previously
assigned addresses expire.
クライアントは新しいＩＡＩＤでサーバにＩＡ＿ＴＡオプションを送ること
によって新しい一時的なアドレスを得ます。サーバから新しい一時的なアド
レスを求めることは、ＲＦＣ３０４１で記述される新しい一時的なアドレス
を生成することと等価です。サーバは新しい一時的なアドレスを生成し、そ
してクライアントにそれらを帰すでしょう。クライアントは、前に割り当て
られたアドレスの寿命が切れる前に、新しい一時的なアドレスを求めるべき
です。
A server MUST return the same set of temporary address for the same
IA_TA (as identified by the IAID) as long as those addresses are
still valid. After the lifetimes of the addresses in an IA_TA have
expired, the IAID may be reused to identify a new IA_TA with new
temporary addresses.
サーバはそれらのアドレスがまだ正当である限り、（ＩＡＩＤで識別される）
ＩＡ＿ＴＡに対して、同じ一時的アドレスを返さなくてはなりません(MUST)。
ＩＡ＿ＴＡのアドレスの寿命が切れた後、ＩＡＩＤは新しい一時的アドレス
の新しいＩＡ＿ＡＴを識別するために再利用されるかもしれません。
This option MAY appear in a Confirm message if the lifetimes on the
temporary addresses in the associated IA have not expired.
このオプションは、もし関連したＩＡの一時的アドレスの寿命が切れなかっ
たなら、確証メッセージに現われるかもしれません(MAY)。
22.6. IA Address Option
22.6. ＩＡアドレスオプション
The IA Address option is used to specify IPv6 addresses associated
with an IA_NA or an IA_TA. The IA Address option must be
encapsulated in the Options field of an IA_NA or IA_TA option. The
Options field encapsulates those options that are specific to this
address.
ＩＡアドレスオプションはＩＡ＿ＮＡかＩＡ＿ＴＡと関連したＩＰｖ６アド
レスを指定するために使われます。ＩＡアドレスオプションはＩＡ＿ＮＡか
ＩＡ＿ＴＡオプションのオプションフィールドでまとめられなくてはなりま
せん。オプションフィールドはこららのオプションをまとめ、これはこのア
ドレスに固有です。
The format of the IA Address option is:
ＩＡアドレスオプショのフォーマットは以下です：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IAADDR | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| preferred-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IAaddr-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_IAADDR (5).
option-len 24 + length of IAaddr-options field.
２４＋ＩＡアドレスオプションフィールドの長さ
IPv6 address An IPv6 address.
ＩＰｖ６アドレス
preferred-lifetime The preferred lifetime for the IPv6 address in
the option, expressed in units of seconds.
秒単位で表現される、オプションのＩＰｖ６アドレスのた
めの望ましい寿命。
valid-lifetime The valid lifetime for the IPv6 address in the
option, expressed in units of seconds.
秒単位で表現される、オプションのＩＰｖ６アドレスのた
めの正式な寿命。
IAaddr-options Options associated with this address.
このアドレスと関連したオプション。
In a message sent by a client to a server, values in the preferred
and valid lifetime fields indicate the client's preference for those
parameters. The client may send 0 if it has no preference for the
preferred and valid lifetimes. In a message sent by a server to a
client, the client MUST use the values in the preferred and valid
lifetime fields for the preferred and valid lifetimes. The values in
the preferred and valid lifetimes are the number of seconds remaining
in each lifetime.
クライアントからサーバに送られたメッセージで、クライアントがこのパラ
メータに望む好ましい寿命と正式寿命フィールドの値を示します。クライア
ントは、もし好ましい寿命と正式寿命の望みを持っていないなら、０を送っ
てもよいです。サーバからクライアントに送られたメッセージで、クライア
ントは好ましい寿命と正式寿命のために好ましい寿命と正式寿命フィールド
の値を使わなくてはなりません(MUST)。好ましい寿命と正式寿命の値はそれ
ぞれの寿命の残りの秒数です。
A client discards any addresses for which the preferred lifetime is
greater than the valid lifetime. A server ignores the lifetimes set
by the client if the preferred lifetime is greater than the valid
lifetime and ignores the values for T1 and T2 set by the client if
those values are greater than the preferred lifetime.
クライアントが望ましい寿命が正式な寿命より大きいアドレスでも捨てます。
もしクライアントが設定した望ましい寿命が正式な寿命より大きいなら、サー
バは寿命を無視し、そして、もしクライアントの設定したＴ１とＴ２の値が
望ましい寿命より大きいなら、これらの値を無視します。
Care should be taken in setting the valid lifetime of an address to
0xffffffff ("infinity"), which amounts to a permanent assignment of
an address to a client.
アドレスの正式な寿命を0xffffffff（「無限」）に設定する際に注意をすべ
きで、これはクライアントにアドレスの永遠の割当てになります。
An IA Address option may appear only in an IA_NA option or an IA_TA
option. More than one IA Address Option can appear in an IA_NA
option or an IA_TA option.
ＩＡアドレスオプションがＩＡ＿ＮＡオプションあるいはＩＡ＿ＴＡオプショ
ンにだけ現われるかもしれません。複数のＩＡアドレスオプションがＩＡ＿
ＮＡオプションあるいはＩＡ＿ＴＡオプションに現われることができます。
The status of any operations involving this IA Address is indicated
in a Status Code option in the IAaddr-options field.
このＩＡアドレスに関するオペレーションの状態はＩＡアドレスオプション
フィールドの状態コードで示されます。
22.7. Option Request Option
22.7. オプション要求オプション
The Option Request option is used to identify a list of options in a
message between a client and a server. The format of the Option
Request option is:
オプション要求オプションはクライアントとサーバ間のメッセージでオプショ
ンのリストを確認するために使われます。オプション要求オプションのフォー
マットは以下です：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_ORO | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| requested-option-code-1 | requested-option-code-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_ORO (6).
option-len 2 * number of requested options.
２×要求されたオプションの数
requested-option-code-n The option code for an option requested by
the client.
クライアントが求めたオプションのオプションコード。
A client MAY include an Option Request option in a Solicit, Request,
Renew, Rebind, Confirm or Information-request message to inform the
server about options the client wants the server to send to the
client. A server MAY include an Option Request option in a
Reconfigure option to indicate which options the client should
request from the server.
クライアントがサーバに送ってもらいたいオプションをサーバに知らせるた
め、クライアントが要請や要求や更新や再結合や確証や情報要求メッセージ
にオプション要求オプションを含めるかもしれません(MAY。サーバがクライ
アントがサーバに要求すべきオプションを再設定オプションのオプション要
求オプションに含めるかもしれません(MAY)。
22.8. Preference Option
22.8. 優先オプション
The Preference option is sent by a server to a client to affect the
selection of a server by the client.
優先オプションはクライアントがサーバを選択する際に影響を与えるために、
サーバからクライアントに送られます。
The format of the Preference option is:
優先オプションフォーマットは以下です：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_PREFERENCE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pref-value |
+-+-+-+-+-+-+-+-+
option-code OPTION_PREFERENCE (7).
option-len 1.
pref-value The preference value for the server in this message.
このメッセージでのサーバの優先値。
A server MAY include a Preference option in an Advertise message to
control the selection of a server by the client. See section 17.1.3
for the use of the Preference option by the client and the
interpretation of Preference option data value.
サーバがクライアントのサーバ選択を制御するために広告メッセージに優先
オプションを含めてもよいです(MAY)。クライアントの優先オプションの使い
方と優先オプションデータ価値の解釈は１７.１.３章を見てください。
22.9. Elapsed Time Option
22.9. 経過時間オプション
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_ELAPSED_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| elapsed-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_ELAPSED_TIME (8).
option-len 2.
elapsed-time The amount of time since the client began its
current DHCP transaction. This time is expressed in
hundredths of a second (10^-2 seconds).
クライアントが現在のＤＨＣＰ処理を始めてからの時間の
量。この時間は１００分の１秒単位で表現されます
（１０^−２秒）。
A client MUST include an Elapsed Time option in messages to indicate
how long the client has been trying to complete a DHCP message
exchange. The elapsed time is measured from the time at which the
client sent the first message in the message exchange, and the
elapsed-time field is set to 0 in the first message in the message
exchange. Servers and Relay Agents use the data value in this option
as input to policy controlling how a server responds to a client
message. For example, the elapsed time option allows a secondary
DHCP server to respond to a request when a primary server has not
answered in a reasonable time. The elapsed time value is an
unsigned, 16 bit integer. The client uses the value 0xffff to
represent any elapsed time values greater than the largest time value
that can be represented in the Elapsed Time option.
クライアントがどれほど長い間ＤＨＣＰメッセージ交換をしているか示すた
め、メッセージに経過時間オプションを含めなくてはなりません(MUST)。経
過時間はクライアントがメッセージ交換の最初のメッセージを送ったときに
計測を始め、メッセージ交換の最初のメッセージでは経過時間フィールドに
０が設定されます。サーバとリレーエージェントがこのオプションの値を、
どのようにサーバがクライアントメッセージに返答するかの、ポリシー制御
の入力にします。例えば、主サーバが合理的な時間内に答えなかった時、経
過時間オプションは第２ＤＨＣＰサーバが要請に返答することを許します。
経過時間値は符号なし１６ ビット整数です。クライアントは経過時間オプ
ションで表すことができる経過時間でも最も大きい時間値より大きい値を表
すのに値0xffffを使います。
22.10. Relay Message Option
22.10. リレーメッセージオプション
The Relay Message option carries a DHCP message in a Relay-forward or
Relay-reply message.
リレーメッセージオプションはリレー転送あるいはリレー応答メッセージで
ＤＨＣＰメッセージを運びます。
The format of the Relay Message option is:
リレーメッセージオプションのフォーマットは以下です：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RELAY_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. DHCP-relay-message .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_RELAY_MSG (9)
option-len Length of DHCP-relay-message
ＤＨＣＰリレーメッセージの長さ
DHCP-relay-message In a Relay-forward message, the received
message, relayed verbatim to the next relay agent
or server; in a Relay-reply message, the message to
be copied and relayed to the relay agent or client
whose address is in the peer-address field of the
Relay-reply message
リレー転送メッセージで、順番に次のリレーエージェント
あるいはサーバに受信メッセージを伝える；リレー応答
メッセージで、メッセージはコピーされ、リレーエージェ
ントやクライアントに中継されます、そのアドレスはリ
レー応答メッセージの相手アドレスフィールドにあります。
22.11. Authentication Option
22.11. 認証オプション
The Authentication option carries authentication information to
authenticate the identity and contents of DHCP messages. The use of
the Authentication option is described in section 21. The format of
the Authentication option is:
認証オプションはＤＨＣＰメッセージの識別子と内容を認証するための認証
情報を運びます。認証オプションの使用は２１章で記述されます。認証オプ
ションのフォーマットは以下です：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_AUTH | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocol | algorithm | RDM | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| replay detection (64 bits) +-+-+-+-+-+-+-+-+
| | auth-info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. authentication information .
. (variable length) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_AUTH (11)
option-len 11 + length of authentication
information field
１１＋認証情報フィールドの長さ
protocol The authentication protocol used in
this authentication option
この認証オプションで使った認証プロト
コル
algorithm The algorithm used in the
authentication protocol
認証プロトコルで使われるアルゴリズム
RDM The replay detection method used in
this authentication option
この認証オプションで使われる再生発見
方法
Replay detection The replay detection information for
the RDM
ＲＤＭのための再生発見情報
authentication information The authentication information,
as specified by the protocol and
algorithm used in this authentication
option
この認証オプションで使われたプロトコ
ルとアルゴリズムで指定された認証情報
22.12. Server Unicast Option
22.12. サーバーユニキャストオプション
The server sends this option to a client to indicate to the client
that it is allowed to unicast messages to the server. The format of
the Server Unicast option is:
クライアントがサーバへユニキャストメッセージを送れることを示すために、
サーバはクライアントにこのオプションを送ります。サーバユニキャストオ
プションのフォーマットは以下です：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_UNICAST | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| server-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_UNICAST (12).
option-len 16.
server-address The IP address to which the client should send
messages delivered using unicast.
クライアントがユニキャストを使ってメッセージを届け
るべきＩＰアドレス。
The server specifies the IPv6 address to which the client is to send
unicast messages in the server-address field. When a client receives
this option, where permissible and appropriate, the client sends
messages directly to the server using the IPv6 address specified in
the server-address field of the option.
クライアントがユニキャストメッセージを送るはずであるＩＰｖ６アドレス
を、サーバはサーバアドレスフィールドに指定します。クライアントがこの
オプションを受ける時、差し支えなくてそして適切である場合は、クライア
ントはオプションのサーバアドレスフィールドで指定されたＩＰｖ６アドレ
スを使っているサーバに直接メッセージを送ります。
When the server sends a Unicast option to the client, some messages
from the client will not be relayed by Relay Agents, and will not
include Relay Agent options from the Relay Agents. Therefore, a
server should only send a Unicast option to a client when Relay
Agents are not sending Relay Agent options. A DHCP server rejects
any messages sent inappropriately using unicast to ensure that
messages are relayed by Relay Agents when Relay Agent options are in
use.
サーバがクライアントにユニキャストオプションを送る時、あるクライアン
トからのメッセージがリレーエージェントによって中継されないでしょう、
そしてリレーエージェントからのリレーエージェントオプションを含まない
でしょう。それ故に、リレーエージェントがリレーエージェントオプション
を送っていない時、サーバがクライアントにユニキャストオプションだけを
送るべきです。リレーエージェントオプションが使われている時、リレーエー
ジェントによって中継されることを保証するために、ＤＨＣＰサーバがメッ
セージは不適当にユニキャストを使ったメッセージを拒絶します。
Details about when the client may send messages to the server using
unicast are in section 18.
いつクライアントがユニキャストを使ってサーバにメッセージを送ってもよ
いかの詳細は１８章にあります。
22.13. Status Code Option
22.13. 状態コードオプション
This option returns a status indication related to the DHCP message
or option in which it appears. The format of the Status Code option
is:
このオプションは、これが現われるＤＨＣＰメッセージやオプションと関係
する状態表示を返します。状態コードオプションのフォーマットは以下です：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_STATUS_CODE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| status-code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. .
. status-message .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_STATUS_CODE (13).
option-len 2 + length of status-message.
２＋状態メッセージの長さ
status-code The numeric code for the status encoded in
this option. The status codes are defined in
section 24.4.
このオプションでコード化された状態の数値コー
ド。状態コードは２４.４章で定義されます。
status-message A UTF-8 encoded text string suitable for
display to an end user, which MUST NOT be
null-terminated.
エンドユーザに表示に適したＵＴＦ−８でコード
化されたテキスト文字列、これはヌルで終わって
はなりません(MUST NOT)。
A Status Code option may appear in the options field of a DHCP
message and/or in the options field of another option. If the Status
Code option does not appear in a message in which the option could
appear, the status of the message is assumed to be Success.
状態コードオプションがＤＨＣＰメッセージのオプションフィールドや他の
オプションのオプションフィールドに現われるかもしれません。もし状態コー
ドオプションがオプションが現われることができるメッセージに現われない
なら、メッセージの状態は成功と考えられます。
22.14. Rapid Commit Option
22.14. 即時委任オプション
The Rapid Commit option is used to signal the use of the two message
exchange for address assignment. The format of the Rapid Commit
option is:
即時委任オプションはアドレス割当てで２つのメッセージの交換の使用を示
すために使われます。即時委任オプションのフォーマットは以下です：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RAPID_COMMIT | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_RAPID_COMMIT (14).
option-len 0.
A client MAY include this option in a Solicit message if the client
is prepared to perform the Solicit-Reply message exchange described
in section 17.1.1.
もしクライアントが１７.１.１章で記述した要請−応答メッセージ交換を行
う用意ができているなら、 クライアントは要請メッセージにこのオプション
を含めてもよいです(MAY)。
A server MUST include this option in a Reply message sent in response
to a Solicit message when completing the Solicit-Reply message
exchange.
要請−応答メッセージ交換を完了する時、サーバは要請メッセージに応えて
送る応答メッセージにこのオプションを含めなくてはなりません(MUST)。
DISCUSSION:
議論：
Each server that responds with a Reply to a Solicit that includes
a Rapid Commit option will commit the assigned addresses in the
Reply message to the client, and will not receive any confirmation
that the client has received the Reply message. Therefore, if
more than one server responds to a Solicit that includes a Rapid
Commit option, some servers will commit addresses that are not
actually used by the client.
即時委任オプションを含む要請に返答する各サーバは応答メッセージでク
ライアントに割り当てるアドレスを委任するでしょう、そしてサーバはク
ライアントが応答メッセージを受け取ったという確認を受け取らないでしょ
う。それ故に、もし１つ以上のサーバが即時委任オプションを含む要請に
返答するなら、あるサーバが実際にはクライアントに使われないアドレス
を委任するでしょう。
The problem of unused addresses can be minimized, for example, by
designing the DHCP service so that only one server responds to the
Solicit or by using relatively short lifetimes for assigned
addresses.
使われていないアドレスの問題は、例えば、ただ１つだけのサーバが要請
に返答するようにＤＨＣＰサービスを設計することによって、あるいは割
り当てられたアドレスに比較的短い寿命を使うことによって、最小にされ
ることができます。
22.15. User Class Option
22.15. ユーザクラスオプション
The User Class option is used by a client to identify the type or
category of user or applications it represents.
ユーザクラスオプションはそれが表すユーザあるいはアプリケーションのタ
イプあるいはカテゴリーを指定するためにクライアントによって使われます。
The format of the User Class option is:
ユーザクラスオプションのフォーマットは以下です：
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_USER_CLASS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. user-class-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_USER_CLASS (15).
option-len Length of user class data field.
ユーザクラスデータフィールドの長さ
user-class-data The user classes carried by the client.
クライアントによって運ばれるユーザクラス
The information contained in the data area of this option is
contained in one or more opaque fields that represent the user class
or classes of which the client is a member. A server selects
configuration information for the client based on the classes
identified in this option. For example, the User Class option can be
used to configure all clients of people in the accounting department
with a different printer than clients of people in the marketing
department. The user class information carried in this option MUST
be configurable on the client.
このオプションのデータエリアの情報は、クライアントがメンバーであるユー
ザクラスを表現する１つ以上の不透明なフィールドを含んでいます。サーバ
がこのオプションで識別されたクラスに基づき、クライアントの設定情報を
選択します。例えば、ユーザクラスオプションは会計課のクライアントに営
業課のクライアントと異なるプリンタを設定するために使うことができます。
このオプションで運ばれたユーザクラス情報はクライアント上で設定可能に
違いありません(MUST)。
The data area of the user class option MUST contain one or more
instances of user class data. Each instance of the user class data
is formatted as follows:
ユーザクラスオプションのデータエリアは１つ以上のユーザクラスデータを
含んでいなくてはなりません(MUST)。それぞれのユーザクラスデータが次の
ようにフォーマットされます：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| user-class-len | opaque-data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
The user-class-len is two octets long and specifies the length of the
opaque user class data in network byte order.
ユーザクラス長は２オクテット長で、そしてネットワークバイト順で不透明
なユーザクラスデータの長さを指定します。
A server interprets the classes identified in this option according
to its configuration to select the appropriate configuration
information for the client. A server may use only those user classes
that it is configured to interpret in selecting configuration
information for a client and ignore any other user classes. In
response to a message containing a User Class option, a server
includes a User Class option containing those classes that were
successfully interpreted by the server, so that the client can be
informed of the classes interpreted by the server.
サーバは、クライアントの適切な設定情報を選ぶための設定に従って、この
オプションで指定されたクラスを解釈します。サーバがクライアントの設定
情報を選択するために解釈すると設定されたクラスだけを使い、他のユーザ
クラスを無視してもよいです。ユーザクラスオプションを含むメッセージの
応答で、サーバによって解釈されたクラスを含んでいるユーザークラスオプ
ションを差^場は返し、それでクライアントはサーバが解釈したクラスについ
て知ることができます。
22.16. Vendor Class Option
22.16. ベンダークラスオプション
This option is used by a client to identify the vendor that
manufactured the hardware on which the client is running. The
information contained in the data area of this option is contained in
one or more opaque fields that identify details of the hardware
configuration. The format of the Vendor Class option is:
このオプションはクライアントが走っているハードウェアを生産したベンダー
を識別するためにクライアントによって使われます。このオプションのデー
タエリアに含まれる情報は、ハードウェア設定の細部を識別する１つ以上の
不透明なフィールドを含んでいます。ベンダークラスオプションのフォーマッ
トは以下です：
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_VENDOR_CLASS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. vendor-class-data .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_VENDOR_CLASS (16).
option-len 4 + length of vendor class data field.
４＋ベンダクラスデータフィールドの長さ
enterprise-number The vendor's registered Enterprise Number as
registered with IANA [6].
ＩＡＮＡに登録したベンダの企業番号[6]。
vendor-class-data The hardware configuration of the host on
which the client is running.
クライアントが走っているホストのハードウェア
設定。
The vendor-class-data is composed of a series of separate items, each
of which describes some characteristic of the client's hardware
configuration. Examples of vendor-class-data instances might include
the version of the operating system the client is running or the
amount of memory installed on the client.
ベンダークラスデータは一連の異なる項目で構成され、そしてそれぞれはク
ライアントのハードウェア設定のいずれかの特徴を記述します。ベンダーク
ラスデータの例は、クライアントで走るオペレーティング・システムのバー
ジョンあるいはクライアント上にインストールされたメモリ量のを含むかも
しれません。
Each instance of the vendor-class-data is formatted as follows:
各ベンダークラスデータが次のようにフォーマットされます：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| vendor-class-len | opaque-data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
The vendor-class-len is two octets long and specifies the length of
the opaque vendor class data in network byte order.
ベンダークラス長は２オクテットで、そしてネットワークバイト順で不透明
なベンダークラスデータの長さを指定します。
22.17. Vendor-specific Information Option
22.17. ベンダ固有の情報オプション
This option is used by clients and servers to exchange
vendor-specific information.
この報オプションはベンダ固有の情報を交換するためにクライアントとサー
バによって使われます。
The format of the Vendor-specific Information option is:
ベンダー固有情報オプションのフォーマットは以下です：
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_VENDOR_OPTS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. option-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_VENDOR_OPTS (17)
option-len 4 + length of option-data field
４＋オプションデータフィールド長
enterprise-number The vendor's registered Enterprise Number as
registered with IANA [6].
ＩＡＮＡに登録したベンダの企業番号[6]。
option-data An opaque object of option-len octets,
interpreted by vendor-specific code on the
clients and servers
クライアントとサーバのベンダ固有コードで解釈
されるオプション長オクテットの不透明なオブジェ
クト。
The definition of the information carried in this option is vendor
specific. The vendor is indicated in the enterprise-number field.
Use of vendor-specific information allows enhanced operation,
utilizing additional features in a vendor's DHCP implementation. A
DHCP client that does not receive requested vendor-specific
information will still configure the host device's IPv6 stack to be
functional.
このオプションで運ばれた情報の定義はベンダ固有です。ベンダは企業番号
フィールドで示されます。ベンダ固有の情報の使用は、ベンダのＤＨＣＰ実
装で追加の機能を利用した拡張オペレーションを許します。要求したベンダ
固有情報を受信しないＤＨＣＰクライアントが、ホストのデバイスのＩＰｖ
６スタックが機能するように設定することを要請します。
The encapsulated vendor-specific options field MUST be encoded as a
sequence of code/length/value fields of identical format to the DHCP
options field. The option codes are defined by the vendor identified
in the enterprise-number field and are not managed by IANA. Each of
the encapsulated options is formatted as follows:
カプセル化されるベンダ固有のオプションフィールドはＤＨＣＰオプション
フィールドと同一のフォーマットのコード／長さ／値フィールドの連続とし
てコード化されなくてはなりません(MUST)。オプションコードは企業番号
フィールドで識別されたベンダーによって定義され、ＩＡＮＡによって処理
されません。カプセル化されるオプションのそれぞれが次のようにフォー
マットされます：
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| opt-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. option-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt-code The code for the encapsulated option.
カプセル化オプションのコード。
option-len An unsigned integer giving the length of the
option-data field in this encapsulated option
in octets.
このカプセル化オプションのオプションデータ
フィールドの長さを与えるオクテット単位の符号
なし整数。
option-data The data area for the encapsulated option.
カプセル化オプションのためのデータエリア。
Multiple instances of the Vendor-specific Information option may
appear in a DHCP message. Each instance of the option is interpreted
according to the option codes defined by the vendor identified by the
Enterprise Number in that option.
多数のベンダ固有情報オプションがＤＨＣＰメッセージに現われるかもしれ
ません。各オプションは企業番号で識別されたベンダによって定義されたオ
プションコードで解釈されます。
22.18. Interface-Id Option
22.18. インタフェース識別子オプション
The relay agent MAY send the Interface-id option to identify the
interface on which the client message was received. If a relay agent
receives a Relay-reply message with an Interface-id option, the relay
agent relays the message to the client through the interface
identified by the option.
リレーエージェントはクライアントメッセージを受信したインタフェースを
識別するインタフェース識別子オプションを送るかもしれません(MAY)。もし
リレーエージェントがインタフェース識別子オプション付きのリレー応答メッ
セージを受け取るなら、リレーエージェントはオプションで識別されたイン
タフェースを通してクライアントにメッセージを伝えます。
The format of the Interface ID option is:
インタフェース識別子オプションのフォーマットは以下です：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_INTERFACE_ID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. interface-id .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_INTERFACE_ID (18).
option-len Length of interface-id field.
インターフェース識別子フィールドの長さ
interface-id An opaque value of arbitrary length generated
by the relay agent to identify one of the
relay agent's interfaces.
リレーエージェントのインタフェースの１つを識
別するためにリレーエージェントによって生み出
される任意長の不透明な値。
The server MUST copy the Interface-Id option from the Relay-Forward
message into the Relay-Reply message the server sends to the relay
agent in response to the Relay-Forward message. This option MUST NOT
appear in any message except a Relay-Forward or Relay-Reply message.
サーバはリレー転送メッセージのインタフェース識別子オプションを、サー
バがこのリレー転送メッセージに応えて送るリレー応答メッセージにコピー
しなくてはなりません(MUST)。このオプションはリレー転送とリレー応答メッ
セージ以外に現われてはなりません(MUST NOT)。
Servers MAY use the Interface-ID for parameter assignment policies.
The Interface-ID SHOULD be considered an opaque value, with policies
based on exact match only; that is, the Interface-ID SHOULD NOT be
internally parsed by the server. The Interface-ID value for an
interface SHOULD be stable and remain unchanged, for example, after
the relay agent is restarted; if the Interface-ID changes, a server
will not be able to use it reliably in parameter assignment policies.
サーバがパラメータ割当てポリシーでインタフェースＩＤを使ってもよいで
す(MAY)。インタフェースＩＤは、正確な一致に基づいたポリシーに基づき、
不透明な値と思われるべきです(SHOULD)；すなわち、インタフェースＩＤを
サーバ内部で解析すべきではありません(SHOULD NOT)。インタフェースのた
めのインタフェース識別子値は安定し、そして、例えばリレーエージェント
が再開された後で、変化していないべきです(SHOULD)；もしインタフェース
識別子が変化するなら、サーバがパラメータ割当てポリシーで信頼できるよ
うにこれを使うことが可能ではないでしょう。
22.19. Reconfigure Message Option
22.19. 再設定メッセージオプション
A server includes a Reconfigure Message option in a Reconfigure
message to indicate to the client whether the client responds with a
Renew message or an Information-request message. The format of this
option is:
クライアントが更新メッセージや情報要求メッセージに応答するかどうか示
すため、サーバが再設定メッセージに再設定メッセージオプションを含めま
す。このオプションのフォーマットは以下です：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RECONF_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |
+-+-+-+-+-+-+-+-+
option-code OPTION_RECONF_MSG (19).
option-len 1.
msg-type 5 for Renew message, 11 for
Information-request message.
更新メッセージのためには５、情報要求メッセー
ジのために１１。
The Reconfigure Message option can only appear in a Reconfigure
message.
再設定メッセージオプションは再設定メッセージにだけ現われることができ
ます。
22.20. Reconfigure Accept Option
22.20. 再設定受入オプション
A client uses the Reconfigure Accept option to announce to the server
whether the client is willing to accept Reconfigure messages, and a
server uses this option to tell the client whether or not to accept
Reconfigure messages. The default behavior, in the absence of this
option, means unwillingness to accept Reconfigure messages, or
instruction not to accept Reconfigure messages, for the client and
server messages, respectively. The following figure gives the format
of the Reconfigure Accept option:
クライアントがサーバに、再設定メッセージの受信ができる事を示すため、
再設定受入オプションを使います、そしてサーバがクライアントに再設定メッ
セージを受け入れるべきかどうか言うため、このオプションを使います。こ
のオプションなしでのデフォルト行動は、クライアントとサーバのメッセー
ジのそれぞれで、再設定メッセージの受信を受け入れる気がない、あるいは、
再設定メッセージを受信しない指示を意味します。次の図再設定受入オプショ
ンのフォーマットを与えます：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RECONF_ACCEPT | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_RECONF_ACCEPT (20).
option-len 0.
23. Security Considerations
23. セキュリティの考慮
The threat to DHCP is inherently an insider threat (assuming a
properly configured network where DHCPv6 ports are blocked on the
perimeter gateways of the enterprise). Regardless of the gateway
configuration, however, the potential attacks by insiders and
outsiders are the same.
ＤＨＣＰに対する脅威は本質的に内部の脅威です（ＤＨＣＰｖ６ポートが企
業の境界ゲートウェイ上でふさがれた正確に構成を設定されたネットワーク
を想定しています）。しかしながら、ゲートウェイ設定にかかわらず内部者
と部外者による可能性がある攻撃は同じです。
Use of manually configured preshared keys for IPsec between relay
agents and servers does not defend against replayed DHCP messages.
Replayed messages can represent a DOS attack through exhaustion of
processing resources, but not through mis-configuration or exhaustion
of other resources such as assignable addresses.
ＩＰｓｅｃのためのリレーエージェントとサーバ間の手作業で設定された共
有鍵の使用が再生ＤＨＣＰメッセージからの保護を供給しません。再生され
たメッセージは、設定誤りや割当可能アドレスのような他の資源の浪費では
なく、処理資源の浪費によりサービス妨害攻撃を起こせます、。
One attack specific to a DHCP client is the establishment of a
malicious server with the intent of providing incorrect configuration
information to the client. The motivation for doing so may be to
mount a "man in the middle" attack that causes the client to
communicate with a malicious server instead of a valid server for
some service such as DNS or NTP. The malicious server may also mount
a denial of service attack through misconfiguration of the client
that causes all network communication from the client to fail.
ＤＨＣＰクライアントに特有の１つの攻撃は、クライアントに正しくない設
定情報を供給する意図を持つ悪意があるサーバの設置です。そうする動機は、
クライアントをあるＤＮＳやＮＴＰのようなサービスで正当なサーバの代わ
りに悪意があるサーバと通信をさせる「中間者」攻撃を開始することである
かもしれません。悪意があるサーバはすべてのクライアントからのネットワー
ク通信を失敗させるクライアントの設定誤りを通して同じくサービス妨害攻
撃を開始できます。
There is another threat to DHCP clients from mistakenly or
accidentally configured DHCP servers that answer DHCP client requests
with unintentionally incorrect configuration parameters.
意図しない正しくない設定パラメータでＤＨＣＰクライアントの要求に答え
る、間違ってあるいは偶然に構成を設定されたＤＨＣＰサーバによる、ＤＨ
ＣＰクライアントの脅威があります。
A DHCP client may also be subject to attack through the receipt of a
Reconfigure message from a malicious server that causes the client to
obtain incorrect configuration information from that server. Note
that although a client sends its response (Renew or
Information-request message) through a relay agent and, therefore,
that response will only be received by servers to which DHCP messages
are relayed, a malicious server could send a Reconfigure message to a
client, followed (after an appropriate delay) by a Reply message that
would be accepted by the client. Thus, a malicious server that is
not on the network path between the client and the server may still
be able to mount a Reconfigure attack on a client. The use of
transaction IDs that are cryptographically sound and cannot easily be
predicted will also reduce the probability that such an attack will
be successful.
ＤＨＣＰクライアントが、悪意があるサーバから正しくない設定情報を得さ
せるための悪意があるサーバからの再設定メッセージの受信を通して攻撃を
受けているかもしれません。クライアントが回答（更新あるいは情報要求メッ
セージを更新する）をリレーエージェントを通して送り、そして、それ故に、
その回答がＤＨＣＰメッセージを中継するサーバによって受信されるだけで
あるであろうけれども、悪意があるサーバが再設定メッセージを送った後に
（適切な遅延の後に）、クライアントが受け入れるであろう応答メッセージ
を送ることができることに注意してください。それで、クライアントとサー
バの間のネットワークパス上にない悪意があるサーバがクライアントに対す
る再設定攻撃を開始することが可能であるかもしれません。暗号的に完全で、
そして容易に予言できない取引ＩＤの使用はこのような攻撃が成功する可能
性を減らすでしょう。
The threat specific to a DHCP server is an invalid client
masquerading as a valid client. The motivation for this may be for
theft of service, or to circumvent auditing for any number of
nefarious purposes.
ＤＨＣＰサーバに固有の脅威は正当なクライアントのふりをする無効なクラ
イアントです。この動機はサービスの盗みのためかもしれず、あるいは悪い
目的で監査を避けるためかもしれません。
The threat common to both the client and the server is the resource
"denial of service" (DoS) attack. These attacks typically involve
the exhaustion of available addresses, or the exhaustion of CPU or
network bandwidth, and are present anytime there is a shared
resource.
クライアントとサーバの両方に共通の脅威は資源「サービス妨害」（ＤｏＳ）
攻撃です。これらの攻撃は典型的に利用可能なアドレスの極度の浪費、ある
いはＣＰＵやネットワーク帯域幅の極度の浪費を伴い、そして現在がどこに
でも共有資源があります。
In the case where relay agents add additional options to Relay
Forward messages, the messages exchanged between relay agents and
servers may be used to mount a "man in the middle" or denial of
service attack.
リレーエージェントがリレー転送メッセージにオプションを追加する場合で、
リレーエージェントとサーバ間で交換されたメッセージは「中央者」あるい
はサービス妨害攻撃に使われるかもしれません。
This threat model does not consider the privacy of the contents of
DHCP messages to be important. DHCP is not used to exchange
authentication or configuration information that must be kept secret
from other networks nodes.
この脅威モデルはＤＨＣＰメッセージの中身のプライバシーが重要であると
考えません。ＤＨＣＰは他のネットワークノードに対して秘密にされた交換
認証あるいは設定情報を使いません。
DHCP authentication provides for authentication of the identity of
DHCP clients and servers, and for the integrity of messages delivered
between DHCP clients and servers. DHCP authentication does not
provide any privacy for the contents of DHCP messages.
ＤＨＣＰ認証はＤＨＣＰクライアントとサーバの識別子認証と、ＤＨＣＰク
ライアントとサーバの間のメッセージ配送の完全性の提供のためです。ＤＨ
ＣＰ認証がＤＨＣＰメッセージの中身のプライバシーを提供しません。
The Delayed Authentication protocol described in section 21.4 uses a
secret key that is shared between a client and a server. The use of
a "DHCP realm" in the shared key allows identification of
administrative domains so that a client can select the appropriate
key or keys when roaming between administrative domains. However,
the Delayed Authentication protocol does not define any mechanism for
sharing of keys, so a client may require separate keys for each
administrative domain it encounters. The use of shared keys may not
scale well and does not provide for repudiation of compromised keys.
This protocol is focused on solving the intradomain problem where the
out-of-band exchange of a shared key is feasible.
２１.４章で記述した遅延認証プロトコルはクライアントとサーバで共有する
秘密鍵を使います。共有鍵での「ＤＨＣＰ領域」の使用は、クライアントが
管理上のドメインの間をさまよう時、適切な鍵あるいは鍵を選択することが
できるように、管理上ドメインの身元確認を許します。しかしながら、遅延
認証プロトコルは鍵共有のメカニズムを定義しません、それでクライアント
が遭遇するそれぞれの管理ドメイン毎に別の鍵を必要とするかもしれません。
共有鍵の使用はスケールしないかもしれず、そして漏洩した鍵のの拒絶を供
給しません。このプロトコルは共有鍵のアウトバンド交換が実行可能である
ドメイン間問題を解くことについて焦点を合わせられます。
Because of the opportunity for attack through the Reconfigure
message, a DHCP client MUST discard any Reconfigure message that does
not include authentication or that does not pass the validation
process for the authentication protocol.
再設定メッセージを通しての攻撃の機会のために、ＤＨＣＰクライアントが
認証を含まない、あるいは認証プロトコルの承認プロセスを通らない再設定
メッセージを捨てなくてはなりません(MUST)。
The Reconfigure Key protocol described in section 21.5 provides
protection against the use of a Reconfigure message by a malicious
DHCP server to mount a denial of service or man-in-the-middle attack
on a client. This protocol can be compromised by an attacker that
can intercept the initial message in which the DHCP server sends the
key to the client.
２１.５章で記述された再設定鍵プロトコルは、再設定メッセージの使用の際
の悪意があるＤＨＣＰサーバによるサービス妨害や中間者攻撃に対する保護
を供給します。このプロトコルはＤＨＣＰサーバがクライアントに鍵を送る
最初のメッセージを途中で捕えることができる攻撃者によって危険にされま
す。
Communication between a server and a relay agent, and communication
between relay agents, can be secured through the use of IPSec, as
described in section 21.1. The use of manual configuration and
installation of static keys are acceptable in this instance because
relay agents and the server will belong to the same administrative
domain and the relay agents will require other specific configuration
(for example, configuration of the DHCP server address) as well as
the IPSec configuration.
サーバとリレーエージェントの間の通信と、リレーエージェント同士の間の
通信が、２１.１章で記述されるように、ＩＰｓｅｃの使用を通して保証で
きます。リレーエージェントとサーバが同じ管理者ドメインに属し、リレー
エージェントがＩＰｓｅｃ設定と同じぐらい他の設定を必要とするだろうか
ら（例えば、ＤＨＣＰサーバアドレス設定）、手動設定の使用と静的鍵の導
入は、この場合受容できます。
24. IANA Considerations
24. ＩＡＮＡの考慮
This document defines several new name spaces associated with DHCPv6
and DHCPv6 options:
この文書はＤＨＣＰｖ６とＤＨＣＰｖ６オプションと結び付けられたいくつ
かの新しい名前空間を定義します：
- Message types
メッセージタイプ
- Status codes
状態コード
- DUID
ＤＵＩＤ
- Option codes
オプションコード
IANA has established a registry of values for each of these name
spaces, which are described in the remainder of this section. These
name spaces will be managed by the IANA and all will be managed
separately from the name spaces defined for DHCPv4.
ＩＡＮＡはこれらの名前空間のそれぞれのための値の登記所を設立し、そし
てそれはこの章の残りで記述されます。これらの名前空間はＩＡＮＡによっ
て管理されるでしょう、そして空間の全てはＤＨＣＰｖ４のために定義した
名前とは別に管理されるでしょう。
New multicast addresses, message types, status codes, and DUID types
are assigned via Standards Action [11].
新しいマルチキャストアドレスとメッセージタイプと状態コードとＤＵＩＤ
種別が標準化行動[11]によって割り当てられます。
New DHCP option codes are tentatively assigned after the
specification for the associated option, published as an Internet
Draft, has received expert review by a designated expert [11]. The
final assignment of DHCP option codes is through Standards Action, as
defined in RFC 2434 [11].
新しいＤＨＣＰオプションコードは、関連づけられたオプションの仕様書が
インターネットドラフトとして公開され、指名専門家による専門家レビュー
を受けた後で、仮に割り当てられます[11]。ＤＨＣＰオプションコードの最
終割当ては、ＲＦＣ２４３４[11]で定義されるように、標準化行動を通して
です。
This document also references three name spaces in section 21 that
are associated with the Authentication Option (section 22.11). These
name spaces are defined by the authentication mechanism for DHCPv4 in
RFC 3118 [4].
この文書は同じく認証オプション（２２.１１章）と結び付けられる、２１章
での３つの名前空間を参照します。これらの名前空間はＲＦＣ３１１８[4]の
ＤＨＣＰｖ４の認証メカニズムによって定義されます。
The authentication name spaces currently registered by IANA will
apply to both DHCPv6 and DHCPv4. In the future, specifications that
define new Protocol, Algorithm and RDM mechanisms will explicitly
define whether the new mechanisms are used with DHCPv4, DHCPv6 or
both.
現在ＩＡＮＡによって登録された認証名空間はＤＨＣＰｖ６とＤＨＣＰｖ４
の両方に当てはまるでしょう。将来、新しいプロトコルとアルゴリズムとＲ
ＤＭメカニズムを定義する仕様書は、新しいメカニズムがＤＨＣＰｖ４かＤ
ＨＣＰｖ６かあるいは両方で使われるかを明示的に定義するでしょう。
24.1. Multicast Addresses
24.1. マルチキャストアドレス
Section 5.1 defines the following multicast addresses, which have
been assigned by IANA for use by DHCPv6:
５.１章がＤＨＣＰｖ６で使用するためにＩＡＮＡによって割り当てられた次
のマルチキャストアドレスを定義します：
All_DHCP_Relay_Agents_and_Servers address: FF02::1:2
All_DHCP_Servers address: FF05::1:3
24.2. DHCP Message Types
24.2. ＤＨＣＰメッセージタイプ
IANA has recorded the following message types (defined in section
5.3). IANA will maintain the registry of DHCP message types.
ＩＡＮＡは次のメッセージタイプを記録するように要請されます（５.３章で
定義されます）。ＩＡＮＡはＤＨＣＰメッセージタイプの登録を持続するよ
うに要請されます。
SOLICIT 1
ADVERTISE 2
REQUEST 3
CONFIRM 4
RENEW 5
REBIND 6
REPLY 7
RELEASE 8
DECLINE 9
RECONFIGURE 10
INFORMATION-REQUEST 11
RELAY-FORW 12
RELAY-REPL 13
24.3. DHCP Options
24.3. ＤＨＣＰオプション
IANA has recorded the following option-codes (as defined in section
22). IANA will maintain the registry of DHCP option codes.
ＩＡＮＡは（２２章で定義されるように）次のオプションコードを記録しま
した。ＩＡＮＡはＤＨＣＰオプションコードの登録を持続するでしょう。
OPTION_CLIENTID 1
OPTION_SERVERID 2
OPTION_IA_NA 3
OPTION_IA_TA 4
OPTION_IAADDR 5
OPTION_ORO 6
OPTION_PREFERENCE 7
OPTION_ELAPSED_TIME 8
OPTION_RELAY_MSG 9
OPTION_AUTH 11
OPTION_UNICAST 12
OPTION_STATUS_CODE 13
OPTION_RAPID_COMMIT 14
OPTION_USER_CLASS 15
OPTION_VENDOR_CLASS 16
OPTION_VENDOR_OPTS 17
OPTION_INTERFACE_ID 18
OPTION_RECONF_MSG 19
OPTION_RECONF_ACCEPT 20
24.4. Status Codes
24.4. 状態コード
IANA has recorded the status codes defined in the following table.
IANA will manage the definition of additional status codes in the
future.
ＩＡＮＡは次のテーブルで定義した状態コードを記録しました。ＩＡＮＡ
は将来の追加の状態コードの定義を管理するでしょう。
Name Code Description
---------- ---- -----------
Success 0 Success.
成功
UnspecFail 1 Failure, reason unspecified; this
status code is sent by either a client
or a server to indicate a failure
not explicitly specified in this
document.
特定されていない理由で失敗；この文書で明示されない
理由での失敗を示すため、クライアントかサーバによっ
て送られます。
NoAddrsAvail 2 Server has no addresses available to assign to
the IA(s).
サーバがＩＡに割り当てるためにすぐ利用できるアドレ
スを持っていません。
NoBinding 3 Client record (binding) unavailable.
利用できないクライアントレコード（結合）。
NotOnLink 4 The prefix for the address is not appropriate for
the link to which the client is attached.
アドレスのプレフィックスはクライアントが接続するリ
ンクに適切ではありません。
UseMulticast 5 Sent by a server to a client to force the
client to send messages to the server.
using the All_DHCP_Relay_Agents_and_Servers
address.
クライアントが全ＤＨＣＰリレーエージェントアンドサー
バアドレスを使ってサーバーにメッセージを送ることを
強いるためにサーバからクライアントに送信。
24.5. DUID
24.5. ＤＵＩＤ
IANA has recorded the following DUID types (as defined in section
9.1). IANA will manage the definition of additional DUID types in
the future.
ＩＡＮＡは（９.１章で定義されるように）次のＤＵＩＤタイプを記録しまし
た。ＩＡＮＡは将来追加のＤＵＩＤタイプの定義を管理するでしょう。
DUID-LLT 1
DUID-EN 2
DUID-LL 3
25. Acknowledgments
25. 謝辞
Thanks to the DHC Working Group and the members of the IETF for their
time and input into the specification. In particular, thanks also
for the consistent input, ideas, and review by (in alphabetical
order) Bernard Aboba, Bill Arbaugh, Thirumalesh Bhat, Steve Bellovin,
A. K. Vijayabhaskar, Brian Carpenter, Matt Crawford, Francis Dupont,
Richard Hussong, Kim Kinnear, Fredrik Lindholm, Tony Lindstrom, Josh
Littlefield, Gerald Maguire, Jack McCann, Shin Miyakawa, Thomas
Narten, Erik Nordmark, Jarno Rajahalme, Yakov Rekhter, Mark Stapp,
Matt Thomas, Sue Thomson, Tatuya Jinmei and Phil Wells.
この仕様書への時間と入力のためにＤＨＣ作業グループとＩＥＴＦメンバー
に感謝します。特に、同じく整合性がある入力と考えと検討に対し、
Bernard AbobaとBill ArbaughとThirumalesh BhatとSteve Bellovinと
A. K. VijayabhaskarとBrian CarpenterとMatt CrawfordとFrancis Dupont
とRichard HussongとKim KinnearとFredrik LindholmとTony Lindstromと
Josh LittlefieldとGerald MaguireとJack McCannとShin Miyakawaと
Thomas NartenとErik NordmarkとJarno RajahalmeとYakov Rekhterと
Mark StappとMatt ThomasとSue ThomsonとTatuya Jinmeiand PhilWells
（アルファベット順）に感謝します。
Thanks to Steve Deering and Bob Hinden, who have consistently taken
the time to discuss the more complex parts of the IPv6
specifications.
ＩＰｖ６仕様書の複雑な部分を論じるのに時間をかけたSteve Deeringと
Bob Hindenに感謝します。
And, thanks to Steve Deering for pointing out at IETF 51 in London
that the DHCPv6 specification has the highest revision number of any
Internet Draft.
そして、ロンドンのＩＥＴＦ５１でＤＨＣＰｖ６仕様書がインターネットド
ラフトで最も大きい版数を指摘した事に対して、Steve Deeringに感謝します。
26. References
26. 参考文献
26.1. Normative References
26.1. 参照する参考文献
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[4] Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for DHCP
Messages", RFC 3118, June 2001.
[5] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[6] IANA. Private Enterprise Numbers.
http://www.iana.org/assignments/enterprise-numbers.html.
[7] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[8] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[9] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation", RFC 1305, March 1992.
[10] Mockapetris, P., "Domain names - implementation and
specification", RFC 1035, November 1987.
[11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[12] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[13] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461, December 1998.
[14] Plummer, D.C., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet address
for transmission on Ethernet hardware", STD 37, RFC 826,
November 1982.
[15] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[16] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[17] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
26.2. Informative References
26.2. 有益な参考文献
[18] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[19] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[20] R. Droms, Ed. DNS Configuration options for DHCPv6. April
2002. Work in Progress.
[21] A. K. Vijayabhaskar. Time Configuration Options for DHCPv6.
May 2002. Work in Progress.
[22] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April
1997.
A. Appearance of Options in Message Types
A. メッセージタイプでのオプションの存在
The following table indicates with a "*" the options are allowed in
each DHCP message type:
次の表の"*"はオプションが各ＤＨＣＰメッセージタイプで許されることを示
します：
Client Server IA_NA Option Pref Time Relay Auth. Server
ID ID IA_TA Request Msg. Unica.
Solicit * * * * *
Advert. * * * * *
Request * * * * * *
Confirm * * * * *
Renew * * * * * *
Rebind * * * * *
Decline * * * * * *
Release * * * * * *
Reply * * * * * *
Reconf. * * * *
Inform. * (see note) * * *
R-forw. * *
R-repl. * *
NOTE:
ノート：
Only included in Information-Request messages that are sent
in response to a Reconfigure (see section 19.4.3).
再設定に応えて送られる情報要請メッセージにだけ含められます
（１９.４.３章参照）を見ます。
Status Rap. User Vendor Vendor Inter. Recon. Recon.
Code Comm. Class Class Spec. ID Msg. Accept
Solicit * * * * *
Advert. * * * * *
Request * * * *
Confirm * * *
Renew * * * *
Rebind * * * *
Decline * * *
Release * * *
Reply * * * * * *
Reconf. *
Inform. * * * *
R-forw. * * * *
R-repl. * * * *
B. Appearance of Options in the Options Field of DHCP Options
B. ＤＨＣＰオプションのオプションフィールドの中のオプションの存在
The following table indicates with a "*" where options can appear in
the options field of other options:
次の表の"*"はオプションが他のオプションのオプションフィールドに現われ
ることができる事を示します：
Option IA_NA/ IAADDR Relay Relay
Field IA_TA Forw. Reply
Client ID *
Server ID *
IA_NA/IA_TA *
IAADDR *
ORO *
Preference *
Elapsed Time *
Relay Message * *
Authentic. *
Server Uni. *
Status Code * * *
Rapid Comm. *
User Class *
Vendor Class *
Vendor Info. *
Interf. ID * *
Reconf. MSG. *
Reconf. Accept *
Note: "Relay Forw" / "Relay Reply" options appear in the options
field of the message but may only appear in these messages.
メモ：「リレー転送」／「リレー応答」オプションはメッセージのオプショ
ンフィールドに現われますが、これらのメッセージに現われるだけかもしれ
ません。
Chair's Address
議長のアドレス
The working group can be contacted via the current chair:
作業グループには現在の議長を通して連絡を取れます：
Ralph Droms
Cisco Systems
1414 Massachusetts Avenue
Boxborough, MA 01719
Phone: (978) 936-1674
EMail: rdroms@cisco.com
Authors' Addresses
著者のアドレス
Jim Bound
Hewlett Packard Corporation
ZK3-3/W20
110 Spit Brook Road
Nashua, NH 03062-2698
USA
Phone: +1 603 884 0062
EMail: Jim.Bound@hp.com
Bernie Volz
116 Hawkins Pond Road
Center Harbor, NH 03226-3103
USA
Phone: +1-508-259-3734
EMail: volz@metrocast.net
Ted Lemon
Nominum, Inc.
950 Charter Street
Redwood City, CA 94043
USA
EMail: Ted.Lemon@nominum.com
Charles E. Perkins
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
Phone: +1-650 625-2986
EMail: charles.perkins@nokia.com
Mike Carney
Sun Microsystems, Inc
17 Network Circle
Menlo Park, CA 94025
USA
Phone: +1-650-786-4171
EMail: michael.carney@sun.com
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (2003). 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 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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。