[要約] RFC 6656は、Cisco SystemsのDHCPv4のサブネット割り当てオプションについての説明です。このRFCの目的は、Ciscoのネットワーク機器を使用してDHCPv4でサブネットを効果的に割り当てる方法を提供することです。
Internet Engineering Task Force (IETF) R. Johnson
Request for Comments: 6656 K. Kinnear
Category: Informational M. Stapp
ISSN: 2070-1721 Cisco Systems, Inc.
July 2012
Description of Cisco Systems' Subnet Allocation Option for DHCPv4
シスコシステムズのDHCPv4のサブネット割り当てオプションの説明
Abstract
概要
This memo documents a DHCPv4 option that currently exists and was previously privately defined for the operation and usage of the Cisco Systems' Subnet Allocation Option for DHCPv4. The option is passed between the DHCPv4 Client and the DHCPv4 Server to request dynamic allocation of a subnet, give specifications of the subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with RFC 3942, which declares that any preexisting usages of option numbers in the range 128-223 should be documented and that the working group will try to officially assign those numbers to those options.
このメモは、現在存在しており、以前はCisco SystemsのDHCPv4のサブネット割り当てオプションの操作と使用法について非公開で定義されていたDHCPv4オプションについて説明しています。 DHCPv4クライアントとDHCPv4サーバーの間でオプションが渡され、サブネットの動的割り当てを要求し、割り当てられたサブネットの仕様を提供し、使用統計を報告します。このメモは、RFC 3942に準拠したオプションの現在の使用法を文書化しています。RFC3942は、128〜223の範囲のオプション番号の既存の使用法を文書化し、ワーキンググループがそれらの番号をこれらのオプションに正式に割り当てようとすることを宣言しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6656.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6656で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部の著作権を管理する人は、IETFトラストにそのような素材の変更を許可する権利を付与していないIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Subnet Allocation Option Format . . . . . . . . . . . . . . . 5
3.1. Subnet-Request Suboption Format . . . . . . . . . . . . . 5
3.2. Subnet-Information Suboption Format . . . . . . . . . . . 7
3.2.1. Subnet Prefix Information Block Format . . . . . . . . 8
3.3. Subnet-Name Suboption Format . . . . . . . . . . . . . . . 9
3.4. Suggested-Lease-Time Suboption Format . . . . . . . . . . 10
4. Requesting Allocation of a Subnet . . . . . . . . . . . . . . 10
4.1. Client DHCPDISCOVER Message . . . . . . . . . . . . . . . 11
4.2. Server DHCPOFFER Message . . . . . . . . . . . . . . . . . 11
4.3. Client DHCPREQUEST Message . . . . . . . . . . . . . . . . 12
4.4. Server DHCPACK Message . . . . . . . . . . . . . . . . . . 13
5. Client Renewal of Subnet Lease . . . . . . . . . . . . . . . . 13
5.1. Client RENEW DHCPREQUEST Message . . . . . . . . . . . . . 13
5.2. Server RENEW DHCPREQUEST Response . . . . . . . . . . . . 14
5.3. Client DHCPRELEASE Message . . . . . . . . . . . . . . . . 14
5.4. Server DHCPFORCERENEW Message . . . . . . . . . . . . . . 15
6. Client Requesting Previously Allocated Subnet Information . . 15
6.1. Initial Client DHCPDISCOVER Message . . . . . . . . . . . 15
6.2. Initial Server DHCPOFFER Response . . . . . . . . . . . . 16
6.3. Additional Client DHCPDISCOVER Messages . . . . . . . . . 16
6.4. Additional Server DHCPOFFER Responses . . . . . . . . . . 16
7. DHCP Server Subnet Allocation Method . . . . . . . . . . . . . 17
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Differences from DHCPv6 Prefix Delegation . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23
This memo documents a DHCP option [RFC2132], the Subnet Allocation option, that was developed by Cisco and allows a DHCP Client to allocate a subnet given information from a DHCP Server. This protocol makes use of DHCP option number 220, one of the option numbers reclassified by [RFC3942]. That RFC specifies in Section 4, procedure 2, "Vendors that currently use one or more of the reclassified options have 6 months following this RFC's publication date to notify the DHC WG and IANA that they are using particular options numbers and agree to document that usage in an RFC". This memo serves as that documentation. The DHC WG has had no input into any of the details of the protocol operation and makes no statement about the correctness or any other aspect of the protocol. The WG also has seen no interest in further implementation or deployment of this protocol other than privately, and therefore has decided to publish this document solely for informational purposes.
このメモは、シスコが開発したDHCPオプション[RFC2132]であるサブネット割り当てオプションについて説明しており、DHCPクライアントがDHCPサーバーからの情報を基にサブネットを割り当てることができます。このプロトコルは、DHCPオプション番号220を利用します。これは、[RFC3942]によって再分類されたオプション番号の1つです。そのRFCは、セクション4、手順2で指定されています。「1つ以上の再分類されたオプションを現在使用しているベンダーは、このRFCの発行日から6か月後に特定のオプション番号を使用していることをDHC WGおよびIANAに通知し、その使用法を文書化することに同意します。 RFCで」。このメモはそのドキュメントとして役立ちます。 DHC WGは、プロトコル操作の詳細について何も入力しておらず、プロトコルの正確性やその他の側面については何も述べていません。 WGはまた、このプロトコルの個人的な実施以外の実装や展開に関心がないため、情報提供のみを目的としてこのドキュメントを公開することを決定しました。
The Subnet Allocation option provides a straightforward way to allocate a subnet from DHCP, useful for a simple Dial-in Aggregation box, or to implement a Hierarchical chain of DHCP Servers, each one in turn leasing one or more subnets to the next DHCP Server down the chain. This option is specified in such a way as to use one DHCP option number, while using suboption numbers for each function.
サブネット割り当てオプションは、DHCPからサブネットを割り当てる簡単な方法を提供します。これは、単純なダイヤルイン集約ボックスに役立ちます。またはDHCPサーバーの階層チェーンを実装し、それぞれが1つ以上のサブネットを次のDHCPサーバーにリースしますチェーン。このオプションは、1つのDHCPオプション番号を使用し、各機能にサブオプション番号を使用するように指定されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document also uses the following terms:
このドキュメントでは、次の用語も使用しています。
DHCP Client: DHCP Client or "Client" is an Internet host using DHCP to obtain configuration parameters such as a network address.
DHCPクライアント：DHCPクライアントまたは「クライアント」は、DHCPを使用してネットワークアドレスなどの構成パラメーターを取得するインターネットホストです。
DHCP Server: A DHCP Server or "Server" is an Internet host that returns configuration parameters to DHCP Clients.
DHCPサーバー：DHCPサーバーまたは「サーバー」は、DHCPクライアントに構成パラメーターを返すインターネットホストです。
0 1 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Code | Len | Flags | Suboptions ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Code = Subnet Allocation option code (1 octet): 220 Len = Length of the entire option including all suboptions (1 octet) Flags = Various flags: (None currently defined)
コード=サブネット割り当てオプションコード（1オクテット）：220 Len =すべてのサブオプションを含むオプション全体の長さ（1オクテット）フラグ=さまざまなフラグ：（現在定義されていない）
One or more suboptions may be specified as described below.
以下に説明するように、1つ以上のサブオプションを指定できます。
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 | Len | Flags :i:h| Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Len = Length of the suboption (always 2 for this suboption) (1 octet) Flags = Flags field. (all unused bits must be zero)
Len =サブオプションの長さ（このサブオプションでは常に2）（1オクテット）Flags = Flagsフィールド。 （未使用のビットはすべてゼロでなければなりません）
'h' = Hierarchical flag 1 : Client will be allocating addresses from this subnet. 0 : Client will be relaying DHCP requests to the Server from this subnet. 'i' = Information flag 1 : Client is seeking information about previously allocated subnets. 0 : Client is seeking a new subnet allocation.
'h' =階層フラグ1：クライアントはこのサブネットからアドレスを割り当てます。 0：クライアントはこのサブネットからサーバーにDHCP要求をリレーします。 'i' =情報フラグ1：クライアントは以前に割り当てられたサブネットに関する情報を探しています。 0：クライアントは新しいサブネット割り当てを求めています。
Prefix = Network prefix length requested (0 means no suggested length is given) (1 octet)
Prefix =要求されたネットワークプレフィックス長（0は推奨される長さが指定されていないことを意味します）（1オクテット）
The DHCP Server SHOULD NOT include the Subnet Request suboption in any replies to the DHCP Client. Enough information will be present in the Subnet-Information suboption, such that the Subnet Request suboption is not needed in replies to the Client.
DHCPサーバーは、DHCPクライアントへの応答にサブネット要求サブオプションを含めないでください。 Subnet-Informationサブオプションには十分な情報が含まれているため、クライアントへの応答にSubnet Requestサブオプションは必要ありません。
The DHCP Server SHOULD allocate a subnet with prefix length [RFC4632] less than or equal to the "Prefix" field length specified in the request. In other words, a subnet containing a number of addresses at least the size indicated by the prefix length requested and possibly more. The DHCP Server MAY allocate a subnet with a prefix length greater than that specified in the request (or a subnet with a number of addresses less than requested), but this is not encouraged.
DHCPサーバーは、リクエストで指定された「プレフィックス」フィールド長以下のプレフィックス長[RFC4632]でサブネットを割り当てる必要があります（SHOULD）。言い換えると、少なくとも要求されたプレフィックス長で示されるサイズ以上のアドレスを含むサブネット。 DHCPサーバーは、リクエストで指定されたものより長いプレフィックス長のサブネット（またはリクエストされた数より少ないアドレスのサブネット）を割り当てることができますが、これは推奨されません。
A "Prefix" field size of 0 MAY be specified by the DHCP Client. In this case, no suggested prefix length is given.
「プレフィックス」フィールドサイズ0は、DHCPクライアントによって指定される場合があります。この場合、推奨されるプレフィックス長は指定されていません。
Multiple Subnet-Request suboptions in a DHCP packet indicate that multiple subnets are being requested. Note that multiple occurrences of this suboption MUST NOT be concatenated in the sense of [RFC3396].
DHCPパケットの複数のサブネット要求サブオプションは、複数のサブネットが要求されていることを示します。このサブオプションの複数の出現は、[RFC3396]の意味で連結してはならないことに注意してください。
Each Subnet-Request suboption MUST result in no more than one Subnet-Information suboption in the DHCPOFFER message from the Server, and may result in no Subnet-Information suboptions.
各Subnet-Requestサブオプションは、サーバーからのDHCPOFFERメッセージで1つ以下のSubnet-Informationサブオプションを生成する必要があり、またSubnet-Informationサブオプションを生成しない可能性があります。
The Client MAY also include the Subnet-Information suboption in order to request a particular subnet. In this case, the Client SHOULD only include one Subnet-Request suboption, since it would otherwise be unclear which Subnet-Information suboption referred to which Subnet-Request suboption. Multiple subnet requests can be made by sending multiple DHCPDISCOVER packets.
クライアントはまた特定のサブネットを要求するためにサブネット情報サブオプションを含むかもしれません。この場合、クライアントは1つのサブネット要求サブオプションのみを含める必要があります。そうしないと、どのサブネット情報サブオプションがどのサブネット要求サブオプションを参照したかが明確にならないためです。複数のDHCPDISCOVERパケットを送信することにより、複数のサブネット要求を行うことができます。
Setting the 'h' flag to 1 indicates the Client will be allocating addresses from the allocated subnet(s) itself. This can be thought of as a "Hierarchical DHCP" design in that control of allocation for the subnet(s) will be passed to the Client.
「h」フラグを1に設定すると、クライアントは割り当てられたサブネット自体からアドレスを割り当てることになります。これは、サブネットの割り当ての制御がクライアントに渡されるという点で、「階層DHCP」設計と考えることができます。
Setting the 'h' flag to 0 indicates the Client wants the DHCP Server to retain control over allocation of addresses from the subnet(s). Any address allocation requests on the subnet will be relayed back to the DHCP Server.
「h」フラグを0に設定することは、クライアントがDHCPサーバーにサブネットからのアドレスの割り当てに対する制御を保持してほしいことを示します。サブネット上のアドレス割り当て要求はすべてDHCPサーバーに中継されます。
Setting the 'i' flag to 1 indicates the Client is NOT seeking allocation of any subnets, but is simply seeking information from the Server as to what subnet(s) have been allocated (or reserved) for this Client. If the 'i' flag is set to 1, then the "Prefix" field SHOULD be set to 0 and MUST be ignored by the Server. In this case, the conversation between the Client and the Server will only progress to the DHCPOFFER packet from the Server, giving the information, as described in Section 6 below.
「i」フラグを1に設定すると、クライアントはサブネットの割り当てを求めていませんが、このクライアントに割り当てられている（または予約されている）サブネットに関する情報をサーバーから求めているだけです。 「i」フラグが1に設定されている場合、「プレフィックス」フィールドは0に設定されるべきで（SHOULD）、サーバーによって無視されなければならない（MUST）。この場合、クライアントとサーバー間の会話は、サーバーからのDHCPOFFERパケットにのみ進み、以下のセクション6で説明するように情報を提供します。
Any undefined flags (those other than 'i' and 'h', mentioned above) should be ignored by the DHCP Server.
未定義のフラグ（上記の「i」および「h」以外のもの）は、DHCPサーバーによって無視されます。
0 1 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| 2 | Len | Flags :c:s| SP1, SP2, ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Len = Length of the suboption (min. length of 8) (1 octet) Flags = Various flags that apply to ALL Subnet Prefix Information fields specified in this suboption. Unused flags must be zero.
Len =サブオプションの長さ（最小長は8）（1オクテット）Flags =このサブオプションで指定されたすべてのサブネットプレフィックス情報フィールドに適用されるさまざまなフラグ。未使用のフラグはゼロでなければなりません。
'c' : Client flag (explained below) 1 : This information is in response to a Client request (or has been echoed back by the Client, when asking for the next previously allocated subnet from the Server). 0 : Otherwise. 's' : Server flag (explained below) 1 : Server has additional subnet information for this Client. 0 : Otherwise.
'c'：クライアントフラグ（以下で説明）1：この情報はクライアント要求に応答します（または、サーバーから以前に割り当てられた次のサブネットを要求したときに、クライアントによってエコーバックされます）。 0：それ以外。 's'：サーバーフラグ（以下で説明）1：サーバーには、このクライアントの追加のサブネット情報があります。 0：それ以外。
SP1, SP2, ... Subnet Prefix Information blocks as specified below (variable size)
SP1、SP2、...以下に指定されているサブネットプレフィックス情報ブロック（可変サイズ）
Setting the 'c' flag to 1 indicates this Subnet-Information suboption is in response to a Client request for information from the Server as to what subnet(s) have been allocated. This flag is used in response to a Subnet-Request suboption with the 'i' flag set and should be 0 in other Server responses. Note, the flag is echoed back from the Client to the Server when requesting the "next previously allocated subnet". Another way to think of the 'c' bit would be that it indicates that the subnet information contained in this suboption does not represent a new allocation by the Server or a new request for allocation by the Client, but instead represents previously allocated subnet information.
「c」フラグを1に設定すると、このサブネット情報サブオプションが、割り当てられたサブネットに関するサーバーからの情報を求めるクライアント要求に応答することを示します。このフラグは、「i」フラグが設定されたSubnet-Requestサブオプションに応答して使用され、他のサーバー応答では0でなければなりません。このフラグは、「次に割り当てられた次のサブネット」を要求すると、クライアントからサーバーにエコーバックされます。 「c」ビットを考えるもう1つの方法は、このサブオプションに含まれるサブネット情報がサーバーによる新しい割り当てまたはクライアントによる割り当ての新しい要求を表すのではなく、以前に割り当てられたサブネット情報を表すことです。
Setting the 's' flag to 1 indicates the Server has additional subnet information for the Client.
「s」フラグを1に設定すると、サーバーにクライアントの追加のサブネット情報があることを示します。
Any undefined flags (those other than 'c' and 's', mentioned above) should be ignored by the DHCP Server.
未定義のフラグ（上記の「c」と「s」以外のもの）は、DHCPサーバーによって無視されます。
The Subnet-Information suboption is used by the DHCP Server in order to return information as to what subnets are offered (in the case of a DHCPOFFER packet) or allocated (in the case of a DHCPACK packet). As is indicated above, multiple subnets may be returned in one Subnet-Information suboption.
サブネット情報サブオプションは、提供されているサブネット（DHCPOFFERパケットの場合）または割り当てられているサブネット（DHCPACKパケットの場合）に関する情報を返すためにDHCPサーバーによって使用されます。上記のように、1つのサブネット情報サブオプションで複数のサブネットが返される場合があります。
The Subnet-Information suboption is also used by the DHCP Client in order to request allocation of specific subnets in a DHCPREQUEST packet. In this case, the "Network", "Prefix", and "Flags" fields contained in the associated Subnet Prefix Information blocks MUST NOT be changed from the information that was received in the DHCPOFFER packet from the Server. The Client MAY, however, use multiple Subnet-Information suboptions in order to request subnets that were originally specified by the Server inside one Subnet-Information suboption.
サブネット情報サブオプションは、DHCPREQUESTパケット内の特定のサブネットの割り当てを要求するためにDHCPクライアントでも使用されます。この場合、関連するサブネットプレフィックス情報ブロックに含まれる「ネットワーク」、「プレフィックス」、および「フラグ」フィールドは、サーバーからDHCPOFFERパケットで受信された情報から変更してはなりません。ただし、クライアントは、サーバーによって最初に指定されたサブネットを1つのSubnet-Informationサブオプション内で要求するために、複数のSubnet-Informationサブオプションを使用する場合があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix | Flags :h:d| Stat-len | Optional stats...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network = IPv4 network number (4 octets) Prefix = Prefix length (1 octet) Flags = Flags field (Undefined bits must be zero) (1 octet)
ネットワーク= IPv4ネットワーク番号（4オクテット）プレフィックス=プレフィックス長（1オクテット）フラグ=フラグフィールド（未定義ビットはゼロでなければならない）（1オクテット）
'd' = Deprecate flag (explained below) 1 : Deprecation of this subnet is requested. 0 : No deprecation is needed.
'd' =非推奨フラグ（以下で説明）1：このサブネットの非推奨が要求されています。 0：非推奨は必要ありません。
'h' = Hierarchical flag (explained below) 1 : Client will be allocating addresses from this subnet. 0 : Client will be relaying DHCP requests to the Server from this subnet.
'h' =階層フラグ（以下で説明）1：クライアントはこのサブネットからアドレスを割り当てます。 0：クライアントはこのサブネットからサーバーにDHCP要求をリレーします。
Stat-len = Length of the optional statistics information field (zero if no statistics are included) (1 octet)
Stat-len =オプションの統計情報フィールドの長さ（統計が含まれていない場合はゼロ）（1オクテット）
The 'd' flag may only be returned by the Server to the Client (inside a DHCPACK packet, in response to a DHCP RENEW). Its presence means that the Client should prepare to give up the subnet. For example, if the Client is assigning addresses from this subnet to other Clients, it should cease doing so immediately and should not renew any leases when Clients ask for renewal. As soon as all addresses in the subnet are unallocated, the Client should send a DHCPRELEASE message to the Server, including a Subnet Prefix Information block for the subnet in order to release the subnet. The format of this message is described farther below.
「d」フラグは、サーバーからクライアントにのみ返される場合があります（DHCP RENEWに応答して、DHCPACKパケット内で）。その存在は、クライアントがサブネットを放棄する準備をする必要があることを意味します。たとえば、クライアントがこのサブネットから他のクライアントにアドレスを割り当てている場合、すぐに割り当てを停止し、クライアントが更新を要求したときにリースを更新しないでください。サブネット内のすべてのアドレスの割り当てが解除されるとすぐに、クライアントは、サブネットを解放するために、サブネットのサブネットプレフィックス情報ブロックを含むDHCPRELEASEメッセージをサーバーに送信する必要があります。このメッセージの形式については、後で詳しく説明します。
The 'h' flag tells the Client how the Server intends for the Client to use the allocated subnet. It is interpreted in the same manner as that in the Subnet-Request suboption. In response to a Subnet-Request, the Server should normally specify the 'h' flag in the same manner as it was in the Subnet-Request suboption from the Client. The Server MAY, however, change the 'h' flag from that specified in the Subnet-Request suboption if it has been configured to override the Client's request.
「h」フラグは、サーバーがクライアントに割り当てられたサブネットを使用する方法をクライアントに通知します。 Subnet-Requestサブオプションと同じように解釈されます。サブネット要求に応答して、サーバーは通常、クライアントからのサブネット要求サブオプションと同じ方法で「h」フラグを指定する必要があります。ただし、サーバーは、クライアントの要求を上書きするように構成されている場合、サブネット要求サブオプションで指定されたものから「h」フラグを変更する場合があります。
Any undefined flags (those other than 'd' and 'h', mentioned above) should be ignored by the DHCP Server.
未定義のフラグ（上記の「d」および「h」以外のもの）は、DHCPサーバーによって無視されます。
If any usage statistics information is to be included, then the "Stat-len" field specifies the number of bytes of statistics information that is included. See below for more information. If no statistics information is included, then this byte MUST be zero. The "Stat-len" field SHOULD always be zero when this suboption is sent by the DHCP Server. The usage statistics information is intended for use only to report usage statistics from the Client to the Server.
使用統計情報が含まれる場合、「Stat-len」フィールドは含まれる統計情報のバイト数を指定します。詳細については、以下を参照してください。統計情報が含まれていない場合、このバイトはゼロでなければなりません。このサブオプションがDHCPサーバーによって送信される場合、 "Stat-len"フィールドは常にゼロでなければなりません。使用統計情報は、クライアントからサーバーに使用統計を報告するためにのみ使用することを目的としています。
The Subnet-Information suboption may also include usage statistics information. If this information is included, then the "Stat-len" (Statistics length) field MUST be set to the number of bytes of statistics information that is being included. The statistics information MUST be in the following form and order:
Subnet-Informationサブオプションには、使用統計情報も含まれる場合があります。この情報が含まれている場合、 "Stat-len"（統計長）フィールドは、含まれている統計情報のバイト数に設定する必要があります。統計情報は、次の形式と順序である必要があります。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| High water |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Currently in use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unusable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"High water" refers the to "high-water mark" of allocated addresses within the subnet. That is, the largest number of addresses that were ever allocated at one time from the subnet.
「最高水位」とは、サブネット内で割り当てられたアドレスの「最高水位標」を指します。つまり、サブネットから一度に割り当てられたアドレスの最大数。
"Currently in use" refers to the number of addresses currently allocated in the subnet.
「現在使用中」とは、サブネットに現在割り当てられているアドレスの数を指します。
"Unusable" refers to the number of addresses that are currently unusable for any reason (such as a Client returning a DHCPDECLINE, or finding the address already in use).
「使用不可」とは、何らかの理由（クライアントがDHCPDECLINEを返す、またはすでに使用されているアドレスを見つけるなど）のために現在使用できないアドレスの数を指します。
Additional statistics may be added to this option in the future. If so, they MUST be appended immediately after the already defined statistics fields. All statistics fields MUST remain in the same order. Use the all ones value (0xffff) in order to skip reporting a number for a particular field. Fewer fields may be included than what is specified above; for example, if "Stat-len" is "4", then the "Unusable" field has not been included. All fields that are included MUST remain in order specified here.
今後、このオプションに統計が追加される可能性があります。その場合は、すでに定義されている統計フィールドの直後に追加する必要があります。すべての統計フィールドは同じ順序のままにする必要があります。特定のフィールドの数値のレポートをスキップするには、すべて1の値（0xffff）を使用します。上記で指定したフィールドよりも少ないフィールドが含まれる場合があります。たとえば、「Stat-len」が「4」の場合、「使用不可」フィールドは含まれていません。含まれるすべてのフィールドは、ここで指定された順序のままでなければなりません。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| 3 | Len | Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Len = length of the suboption (min. length of 1) (1 octet)
Len =サブオプションの長さ（最小長1）（1オクテット）
The Subnet-Name suboption may be used in order to pass a subnet name to the Server for use during allocation. This name may be used for any purpose but is intended to tell the Server something extra about the needed subnet; for example, "sales department", "customer 1002", "address pool FOO", or some such. The "name" should NOT be NULL terminated since the "len" field already specifies the length of the name. The "Name" in this suboption MUST be given using UTF-8 [RFC3629].
Subnet-Nameサブオプションは、割り当て時に使用するサーバーにサブネット名を渡すために使用できます。この名前は任意の目的に使用できますが、必要なサブネットについて何か特別なことをサーバーに伝えることを目的としています。たとえば、「営業部門」、「顧客1002」、「アドレスプールFOO」などです。 「len」フィールドはすでに名前の長さを指定しているため、「name」はNULLで終了しないでください。このサブオプションの「名前」は、UTF-8 [RFC3629]を使用して指定する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | Len (4) | t1 | t2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| t3 | t4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Len = length of the suboption (always 4 for this suboption) (1 octet)
Len =サブオプションの長さ（このサブオプションでは常に4）（1オクテット）
The Suggested-Lease-Time suboption MAY be included by the Server in order to suggest the lease time to be used by the Client when allocating addresses from the subnet allocated. The 4-octet value of the lease time is in the same format as that of the "IP Address Lease Time" option (option 51), as described in [RFC2132].
割り当てられたサブネットからアドレスを割り当てるときにクライアントが使用するリース時間を提案するために、提案されたリース時間サブオプションがサーバーに含まれる場合があります。 [RFC2132]で説明されているように、リース時間の4オクテット値は、「IPアドレスリース時間」オプション（オプション51）と同じ形式です。
If included, this suboption MUST appear only once. (Inclusion of multiple such suboptions would result in ambiguity as to which applied to which subnet.) If different suggested lease times are needed, the Server SHOULD, instead, reply with only one offered subnet and should set the "Server flag" in the Subnet-Information suboption to indicate to the Client that it should send another subnet request to gather the others.
含まれる場合、このサブオプションは1回だけ出現する必要があります。 （このようなサブオプションを複数含めると、どのサブネットにどのオプションが適用されるかが曖昧になります。）異なる推奨リース時間が必要な場合、サーバーは、代わりに、提供された1つのサブネットのみで応答し、サブネットに「サーバーフラグ」を設定する必要があります。 -別のサブネット要求を送信して他を収集する必要があることをクライアントに示す情報サブオプション。
The Client SHOULD use a lease time, when allocating addresses from the subnet, that is the lesser of the remaining lease time of the subnet itself and the Suggested-Lease-Time suboption.
クライアントは、サブネットからアドレスを割り当てるときにリース時間を使用する必要があります（SHOULD）。これは、サブネット自体の残りのリース時間と、Suggested-Lease-Timeサブオプションの短い方です。
The DHCP Client creates a DHCPDISCOVER message including the Subnet Allocation option, and its set of suboptions, to request allocation of a subnet. The DHCP Client should include the Subnet-Request suboption, specifying the prefix length of the subnet requested. The 'h' bit should be set to 1 if the Client intends to control allocation of addresses within the subnet itself, or 0 if the Server should retain control of addresses within the subnet. More than one Subnet Allocation option may appear in a DHCPDISCOVER message; however, the Client SHOULD limit the number of requests, noting that the DHCP replies will need to include the Subnet-Information suboption, which takes up more space than the Subnet-Request suboption.
DHCPクライアントは、サブネット割り当てオプションとその一連のサブオプションを含むDHCPDISCOVERメッセージを作成して、サブネットの割り当てを要求します。 DHCPクライアントには、要求されたサブネットのプレフィックス長を指定するSubnet-Requestサブオプションを含める必要があります。 「h」ビットは、クライアントがサブネット自体内のアドレスの割り当てを制御する場合は1に、サーバーがサブネット内のアドレスの制御を保持する場合は0に設定する必要があります。 DHCPDISCOVERメッセージに複数のサブネット割り当てオプションが表示される場合があります。ただし、クライアントは要求の数を制限する必要があります。DHCP応答には、サブネット情報サブオプションを含める必要があるため、サブネット要求サブオプションよりも多くのスペースを使用する必要があることに注意してください。
If more than one subnet is being requested, multiple Subnet-Request suboptions MAY be included or multiple DHCPDISCOVER messages MAY be sent instead. The prefix length field of each Subnet-Request suboption MUST be either 0, or in the range of 1 to 30 inclusive.
複数のサブネットが要求されている場合は、複数のSubnet-Requestサブオプションを含めるか、代わりに複数のDHCPDISCOVERメッセージを送信してもよい（MAY）。各Subnet-Requestサブオプションのプレフィックス長フィールドは、0か、1から30までの範囲でなければなりません。
The DHCP "IP address lease time" option (code 51) MAY be included in the DHCPDISCOVER message to specify the lease time the Client is requesting for the subnet. If not present, no suggested lease time is given.
DHCPの「IPアドレスリース時間」オプション（コード51）は、クライアントがサブネットに対して要求しているリース時間を指定するためにDHCPDISCOVERメッセージに含めることができます。存在しない場合、推奨されるリース時間は与えられません。
The DHCP "Client ID" option (code 61) MAY be included in the DHCPDISCOVER message as it may be used by the Server in performing the subnet allocation.
DHCPの「クライアントID」オプション（コード61）は、DHCPDISCOVERメッセージに含めることができます。これは、サーバーがサブネットの割り当てを実行するときに使用される可能性があるためです。
Upon receiving a DHCPDISCOVER containing the Subnet Allocation option, the DHCP Server SHOULD respond with a DHCPOFFER message including the Subnet-Information suboption in order to specify the subnet(s) that it is willing to allocate to the Client in order to fulfill the request(s).
サブネット割り当てオプションを含むDHCPDISCOVERを受信すると、DHCPサーバーは、要求を満たすためにクライアントに割り当てるサブネットを指定するために、サブネット情報サブオプションを含むDHCPOFFERメッセージで応答する必要があります（SHOULD）。 s）。
The Server need not reserve the subnets that are being offered, but SHOULD not offer the same subnets to another DHCP Client until a reasonable time period (implementation dependent) has passed. (This is similar to normal DHCP address allocation.)
サーバーは提供されているサブネットを予約する必要はありませんが、妥当な期間（実装に依存）が経過するまで、同じサブネットを別のDHCPクライアントに提供してはなりません（SHOULD）。 （これは通常のDHCPアドレス割り当てと同様です。）
The Server MUST NOT include the Subnet-Request suboption in the DHCPOFFER. The same information is already present in the Subnet Information suboption(s) that SHOULD be included in the DHCPOFFER.
サーバーはDHCPOFFERにSubnet-Requestサブオプションを含めてはなりません（MUST NOT）。同じ情報がDHCPOFFERに含まれる必要があるサブネット情報サブオプションにすでに存在しています。
The Server SHOULD also include the IP address lease time option (option 51) in the DHCPOFFER message. This gives the lease time for all subnets given in all Subnet-Request suboptions contained in the DHCPOFFER message. The Server MAY also include the Renewal and/or Rebinding options in order to further control the "T1" and "T2" lease timers of the Client. There MUST be exactly one IP address lease time (and optionally one Rebinding and/or one Renewal option) in the DHCPOFFER message.
サーバーは、DHCPOFFERメッセージにIPアドレスのリース時間オプション（オプション51）も含める必要があります（SHOULD）。これにより、DHCPOFFERメッセージに含まれるすべてのSubnet-Requestサブオプションで指定されたすべてのサブネットのリース時間が提供されます。サーバーは、クライアントの「T1」および「T2」リースタイマーをさらに制御するために、更新および/または再バインドオプションを含む場合があります。 DHCPOFFERメッセージには、IPアドレスのリース期間が1つだけ必要です（オプションで、1つの再バインドオプションまたは1つの更新オプション、あるいはその両方）。
The Server MAY set the "Server flag" ('s') to 1 to indicate that it would like to allocate one or more additional subnet(s) to the Client. This indicates that the Client should send another DHCPDISCOVER message specifying a prefix length field, P, of zero in order to request the additional subnet allocation(s) information. This may be necessary if the subnets are to be allocated with different lease times, for example.
サーバーは、「サーバーフラグ」（ 's'）を1に設定して、1つ以上の追加のサブネットをクライアントに割り当てたいことを示すことができます。これは、追加のサブネット割り当て情報を要求するために、クライアントがゼロのプレフィックス長フィールドPを指定する別のDHCPDISCOVERメッセージを送信する必要があることを示しています。これは、たとえば、サブネットが異なるリース時間で割り当てられる場合に必要になることがあります。
The "Client flag" ('c') MUST be set to 0 to indicate this is a Server response to a Client request for a new subnet allocation and not a response to a request for information about already allocated subnets.
「クライアントフラグ」（ 'c'）は0に設定して、新しいサブネット割り当てのクライアント要求に対するサーバーの応答であり、すでに割り当てられているサブネットに関する情報の要求に対する応答ではないことを示す必要があります。
If the packet contains a Subnet Allocation option, the Server SHOULD set the DHCP yiaddr value to all zeros (0.0.0.0) and the Client MUST ignore fields having to do with address assignment. In other words, a DHCP packet exchange cannot provide subnet allocation and address assignment simultaneously.
パケットにサブネット割り当てオプションが含まれている場合、サーバーはDHCP yiaddr値をすべてゼロ（0.0.0.0）に設定する必要があり（SHOULD）、クライアントはアドレス割り当てに関係するフィールドを無視する必要があります（MUST）。つまり、DHCPパケット交換では、サブネットの割り当てとアドレスの割り当てを同時に行うことはできません。
When sending a DHCPREQUEST, the Client MUST NOT modify any fields of any Subnet-Information suboptions received from the Server. However, the Client MAY choose not to include some Subnet-Information suboptions when issuing the DHCPREQUEST. Subnet-Request suboptions MUST NOT be included in the DHCPREQUEST message; only the Subnet-Information suboption(s) should be included.
DHCPREQUESTを送信するとき、クライアントはサーバーから受信したサブネット情報サブオプションのフィールドを変更してはなりません（MUST NOT）。ただし、クライアントは、DHCPREQUESTを発行するときに、一部のサブネット情報サブオプションを含めないことを選択できます（MAY）。 DHCPREQUESTメッセージにサブネット要求サブオプションを含めることはできません。サブネット情報サブオプションのみを含める必要があります。
The DHCP Server, upon receipt of the Client's DHCPREQUEST message, MAY refuse allocation of any subnets (for example, if they have been allocated elsewhere in the meantime); however, since the Server should have set aside the subnets offered for a short period of time, and since the Client should have requested the subnets within a short period of time after receiving the offer(s) from the Server(s), this last minute rejection should be rare. The DHCP Server MUST NOT change the network number(s) or prefix length(s); however, it MAY remove some Subnet-Information suboptions from the list.
DHCPサーバーは、クライアントのDHCPREQUESTメッセージを受信すると、サブネットの割り当てを拒否できます（たとえば、その間に別の場所に割り当てられている場合）。ただし、サーバーは提供されたサブネットを短期間確保しておく必要があり、クライアントはサーバーから提案を受信した後、短期間でサブネットを要求する必要があるため、この最後のわずかな拒否はまれです。 DHCPサーバーは、ネットワーク番号またはプレフィックス長を変更してはなりません（MUST NOT）。ただし、リストから一部のサブネット情報サブオプションを削除する場合があります。
The Server SHOULD include the IP address lease time option specifying the lease period for all subnet(s) in the DHCPACK. All subnets allocated in one DHCP message will have the same lease time, and only one IP address lease time option must appear in the DHCP message.
サーバーは、DHCPACK内のすべてのサブネットのリース期間を指定するIPアドレスのリース期間オプションを含める必要があります（SHOULD）。 1つのDHCPメッセージで割り当てられたすべてのサブネットは同じリース時間を持ち、1つのIPアドレスリース時間オプションのみがDHCPメッセージに表示される必要があります。
If the Server has internal information that states that the Client should be allocated more subnets than were requested, the Server MAY set the 's' bit in the last Subnet-Information suboption to indicate that the Client needs to request more subnets (as described above).
サーバーに、クライアントに要求されたよりも多くのサブネットを割り当てる必要があることを示す内部情報がある場合、サーバーは最後のサブネット情報サブオプションに「s」ビットを設定して、クライアントがより多くのサブネットを要求する必要があることを示します（上記のとおり）。 ）。
The allocable unit is the tuple (network number, prefix length). Multiple subnets may be allocated in one DHCPACK; however, since there can be only one Lease-time option, each subnet allocated is assigned the same lease time. Each subnet lease tuple (network number, prefix length) MAY be renewed or released individually.
割り当て可能な単位はタプル（ネットワーク番号、プレフィックス長）です。 1つのDHCPACKに複数のサブネットを割り当てることができます。ただし、リース期間オプションは1つしか存在できないため、割り当てられた各サブネットには同じリース期間が割り当てられます。各サブネットリースタプル（ネットワーク番号、プレフィックス長）は、個別に更新または解放できます（MAY）。
The Client MUST renew all subnets allocated with a lease time in much the same manner as renewing an allocated IP address. Renewal timers need not be set in exactly the same manner, however. If Renewal and/or Rebinding options were included in the DHCPACK of the subnet allocation, then these "T1" and "T2" timers should be used just as they would be in the case of address allocation timers.
クライアントは、割り当てられたIPアドレスを更新するのとほぼ同じ方法で、リース時間で割り当てられたすべてのサブネットを更新する必要があります。ただし、更新タイマーをまったく同じ方法で設定する必要はありません。更新および再バインドオプションがサブネット割り当てのDHCPACKに含まれている場合、これらの「T1」および「T2」タイマーは、アドレス割り当てタイマーの場合と同様に使用する必要があります。
The DHCPREQUEST message MUST include a Subnet-Information suboption for which the Client is seeking renewal of the lease. This Subnet-Information suboption may optionally include subnet usage statistics, as described above in Section 3.2 ("Subnet-Information Suboption Format").
DHCPREQUESTメッセージには、クライアントがリースの更新を求めているサブネット情報サブオプションを含める必要があります。セクション3.2（「サブネット情報サブオプションの形式」）で説明したように、このサブネット情報サブオプションには、オプションでサブネット使用統計を含めることができます。
The subnet network number field ("Network") and subnet prefix length field ("Prefix") MUST agree with the values as they were originally allocated to the Client by the Server. In any of the statistics fields (High water, Currently in use, Unusable), a value of all ones (0xffff) SHOULD be used if the Client has no information to report for a statistic.
サブネットネットワーク番号フィールド（「ネットワーク」）およびサブネットプレフィックス長フィールド（「プレフィックス」）は、サーバーによってクライアントに最初に割り当てられた値と一致する必要があります。統計フィールド（高水位、現在使用中、使用不可）のいずれかで、クライアントに統計情報を報告する情報がない場合は、すべて1（0xffff）の値を使用する必要があります（SHOULD）。
The Server MAY respond to a subnet RENEW with either a DHCPACK or DHCPNAK response. If a DHCPNAK response is given, the Client MUST immediately stop using the subnet(s) specified and, if possible, notify all Clients with addresses allocated from this subnet that their addresses are no longer valid. The Client MAY, of course, send a DHCPDISCOVER message containing the Subnet Allocation option and the Subnet-Request suboption in order to acquire another subnet for use. In general, the Server should ask the Client to deprecate subnets by using the 'd' bit of the Subnet-Information suboption in a DHCPACK message (see below).
サーバーはDHCPACKまたはDHCPNAK応答でサブネットRENEWに応答してもよい（MAY）。 DHCPNAK応答が与えられた場合、クライアントは指定されたサブネットの使用を直ちに停止し、可能であれば、このサブネットから割り当てられたアドレスを持つすべてのクライアントに、アドレスが無効であることを通知する必要があります。もちろん、クライアントは、使用する別のサブネットを取得するために、サブネット割り当てオプションとサブネット要求サブオプションを含むDHCPDISCOVERメッセージを送信できます（MAY）。一般に、サーバーはクライアントにDHCPACKメッセージのSubnet-Informationサブオプションの「d」ビットを使用してサブネットを廃止するように要求する必要があります（以下を参照）。
If a DHCPACK response is given, the "Deprecate" ('d') bit of the Flags field in the Subnet-Information suboption may also be set. This indicates the DHCP Client should prepare to stop using this subnet. If the Client is allocating IP addresses for other Clients from this subnet (e.g., via DHCP), the Client SHOULD immediately stop allocating such addresses. Once all allocated addresses in the subnet have been released, the Client SHOULD send a DHCPRELEASE message, including the Subnet-Information suboption (with optional usage statistics) in order to release the subnet(s) back to the Server.
DHCPACK応答が提供される場合、サブネット情報サブオプションのフラグフィールドの「非推奨」（「d」）ビットも設定される場合があります。これは、DHCPクライアントがこのサブネットの使用を停止する準備をする必要があることを示しています。クライアントが他のクライアントにこのサブネットから（たとえば、DHCPを介して）IPアドレスを割り当てている場合、クライアントはそのようなアドレスの割り当てを直ちに停止する必要があります（SHOULD）。サブネットに割り当てられたすべてのアドレスが解放されると、クライアントはサーバーにサブネットを解放するために、サブネット情報サブオプション（オプションの使用統計情報を含む）を含むDHCPRELEASEメッセージを送信する必要があります（SHOULD）。
The DHCP Client SHOULD send a DHCPRELEASE message in order to release allocated subnet(s) back to the Server when it is finished using them. This message MUST NOT include the Subnet-Request suboption, but MUST include one or more Subnet-Information suboptions, and may optionally include usage statistics.
DHCPクライアントは、割り当てられたサブネットを使い終わったときにサーバーに解放するために、DHCPRELEASEメッセージを送信する必要があります（SHOULD）。このメッセージにはSubnet-Requestサブオプションを含めることはできませんが、1つ以上のSubnet-Informationサブオプションを含める必要があり、オプションで使用統計を含めることができます。
The Client MUST release the same subnet(s) of the same prefix length ("Prefix"), as were originally allocated. The Client MAY release a subset of the subnets that were allocated originally. In other words, the allocable unit is the tuple (network number, prefix length). Multiple subnets may be allocated in one DHCPACK; however, each subnet MAY be released individually.
クライアントは、最初に割り当てられたのと同じプレフィックス長（ "Prefix"）の同じサブネットを解放する必要があります。クライアントは、最初に割り当てられたサブネットのサブセットを解放してもよい（MAY）。つまり、割り当て可能な単位はタプル（ネットワーク番号、プレフィックス長）です。 1つのDHCPACKに複数のサブネットを割り当てることができます。ただし、各サブネットは個別に解放される場合があります。
The DHCP Server MAY issue a DHCPFORCERENEW [RFC3203] message containing the Subnet Allocation option and the Subnet-Information suboption. Upon receiving this message, the DHCP Client MUST issue a DHCPREQUEST message to the DHCP Server in order to renew the lease on the subnet mentioned. No other subnets allocated to the Client are affected. As is the case with all DHCP RENEW messages, the Client may include subnet usage information in the Subnet-Information suboption in order to report subnet usage statistics, or set the "Stat-len" field to 0 if no statistics are to be reported.
DHCPサーバーは、サブネット割り当てオプションとサブネット情報サブオプションを含むDHCPFORCERENEW [RFC3203]メッセージを発行してもよい（MAY）。このメッセージを受信すると、DHCPクライアントは、言及されたサブネットのリースを更新するために、DHCPサーバーにDHCPREQUESTメッセージを発行する必要があります。クライアントに割り当てられた他のサブネットは影響を受けません。すべてのDHCP RENEWメッセージの場合と同様に、クライアントは、サブネット使用統計を報告するためにサブネット情報サブオプションにサブネット使用情報を含めるか、統計が報告されない場合は "Stat-len"フィールドを0に設定します。
If the Server responds to this DHCPREQUEST with a DHCPNAK message, then the Client MUST immediately stop using the subnet(s) and, if possible, notify all Clients with addresses allocated from this/these subnet(s) that their addresses are no longer valid. The Client MAY, of course, send a DHCPDISCOVER message containing the Subnet Allocation option and the Subnet-Request suboption in order to acquire another subnet for use.
サーバーがDHCPNAKメッセージでこのDHCPREQUESTに応答する場合、クライアントはサブネットの使用をただちに停止し、可能であれば、この/これらのサブネットから割り当てられたアドレスを持つすべてのクライアントにアドレスが無効であることを通知する必要があります。もちろん、クライアントは、使用する別のサブネットを取得するために、サブネット割り当てオプションとサブネット要求サブオプションを含むDHCPDISCOVERメッセージを送信できます（MAY）。
A DHCP Client MAY request from the DHCP Server a list of what subnets are currently allocated to the Client. This may be used to recover from a restart if the Client does not have local storage in order to retain the information itself. (For an example of this, see Section 8.2 below.)
DHCPクライアントは、DHCPサーバーからクライアントに現在割り当てられているサブネットのリストを要求する場合があります。これは、情報自体を保持するためにクライアントにローカルストレージがない場合に、再起動から回復するために使用できます。 （この例については、以下のセクション8.2を参照してください。）
The DHCP Client DHCPDISCOVER message, when used to discover already allocated subnet information, SHOULD contain a Subnet-Request suboption with the "Prefix" field set to 0 and with the 'i' flag set to 1 to indicate that the Client is seeking already allocated subnet information from the Server. No Subnet-Information suboptions should be included in this message. Note, no Subnet-Information suboption is included in this message, since the Client would not know of any subnet to request at that point.
DHCPクライアントDHCPDISCOVERメッセージは、すでに割り当てられているサブネット情報を検出するために使用される場合、「プレフィックス」フィールドが0に設定され、「i」フラグが1に設定され、クライアントがすでに割り当て済みであることを示すSubnet-Requestサブオプションを含む必要があります（SHOULD）。サーバーからのサブネット情報。このメッセージには、サブネット情報サブオプションを含めないでください。クライアントはその時点で要求するサブネットを知らないため、このメッセージにはSubnet-Informationサブオプションが含まれていないことに注意してください。
This DHCPDISCOVER message MAY be unicast to a particular DHCP Server, or broadcast in the normal fashion.
このDHCPDISCOVERメッセージは、特定のDHCPサーバーにユニキャストされる場合と、通常の方法でブロードキャストされる場合があります。
Any DHCP Server that has allocated subnets to the Client SHOULD respond to the DHCPDISCOVER message with a DHCPOFFER message. The DHCPOFFER message should contain one or more Subnet-Information suboption(s) telling the prefix of the subnet(s) allocated to the Client.
クライアントにサブネットを割り当てたDHCPサーバーは、DHCPOFFERメッセージでDHCPDISCOVERメッセージに応答する必要があります（SHOULD）。 DHCPOFFERメッセージには、クライアントに割り当てられたサブネットのプレフィックスを通知する1つ以上のサブネット情報サブオプションが含まれている必要があります。
The Server SHOULD, internally, retain an ordered list of subnets that are allocated to each Client. In response to an initial DHCPDISCOVER message requesting allocated subnet information (i.e., one with the 'i' flag set to 1, but not carrying a Subnet-Information suboption), the Server returns in the DHCPOFFER message the subnet information for the first subnet(s) from this list. If the end of the list has been reached, then the 's' bit of the last Subnet-Information suboption included in the message MUST be set to 0. If there are more subnets in the list, the 's' bit MUST be set to 1 to indicate to the Client that more information is available. Since this information is in response to a Client request for previously allocated subnet information, the 'c' bit MUST be set to 1.
サーバーは内部的に、各クライアントに割り当てられたサブネットの順序付きリストを保持する必要があります（SHOULD）。割り当てられたサブネット情報を要求する最初のDHCPDISCOVERメッセージ（つまり、「i」フラグが1に設定されているが、サブネット情報サブオプションを持たないもの）に応答して、サーバーはDHCPOFFERメッセージで最初のサブネットのサブネット情報を返します（ s）このリストから。リストの最後に達した場合、メッセージに含まれる最後のサブネット情報サブオプションの「s」ビットを0に設定する必要があります。リストにさらにサブネットがある場合は、「s」ビットを設定する必要がありますより多くの情報が利用可能であることをクライアントに示すために1に。この情報は、以前に割り当てられたサブネット情報に対するクライアントの要求に応答するため、「c」ビットを1に設定する必要があります。
The Client, upon receiving any Server DHCPOFFER messages containing Subnet Information suboption information with the 'c' ("Client") bit set, SHOULD gather the network number ("Network") and prefix length ("Prefix") information from the message.
クライアントは、「c」（「クライアント」）ビットが設定されたサブネット情報サブオプション情報を含むサーバーDHCPOFFERメッセージを受信すると、メッセージからネットワーク番号（「ネットワーク」）およびプレフィックス長（「プレフィックス」）情報を収集する必要があります。
If the 's' bit is set in the last of the Subnet-Information suboptions included in the message, then the Client SHOULD construct a new DHCPDISCOVER message containing the Subnet Allocation option and the last Subnet-Information suboption from the Server's message. This message SHOULD then be sent back to the same DHCP Server originating the DHCPOFFER message. The 'c' and 's' bits MUST retain the same settings they had from the Server's DHCPOFFER message and the network number ("Network") and prefix length ("Prefix") fields MUST be unaltered as well.
メッセージに含まれるサブネット情報サブオプションの最後に「s」ビットが設定されている場合、クライアントは、サブネット割り当てオプションとサーバーのメッセージからの最後のサブネット情報サブオプションを含む新しいDHCPDISCOVERメッセージを作成する必要があります（SHOULD）。次に、このメッセージは、DHCPOFFERメッセージを発信した同じDHCPサーバーに送り返される必要があります（SHOULD）。 「c」および「s」ビットは、サーバーのDHCPOFFERメッセージからの設定と同じ設定を保持する必要があり、ネットワーク番号（「Network」）およびプレフィックス長（「Prefix」）フィールドも変更しないでください。
If the 's' bit in all of the Subnet-Information suboptions from the Server was 0, then it indicates the Server has no more information about subnets allocated to the Client.
サーバーからのすべてのサブネット情報サブオプションの「s」ビットが0の場合、サーバーにクライアントに割り当てられたサブネットに関する情報がないことを示しています。
The Server, upon receiving from a Client an additional DHCPDISCOVER message for allocated subnet information retrieval, with the 'i' flag set to 1 and containing one or more Subnet Information suboptions with the 'c' and the 's' bits set, MUST use the network number ("Network") and prefix length ("Prefix") fields contained in the last such Subnet Information suboption. This is in order to locate the position in the internal table of allocated subnets for this Client. Then, the Server MUST return an DHCPOFFER message containing a Subnet-Information suboption giving information about the next set of subnets allocated to this Client. If this finishes the list in the table for this Client, then the 's' bit MUST be set to 0 to indicate there is no more information. Any Subnet Information suboptions encountered without both the 'c' and 's' bits set should be ignored by the Server.
サーバーは、クライアントから割り当てられたサブネット情報取得用の追加のDHCPDISCOVERメッセージを受信すると、「i」フラグが1に設定され、「c」および「s」ビットが設定された1つ以上のサブネット情報サブオプションを含みます。最後のそのようなサブネット情報サブオプションに含まれるネットワーク番号（「ネットワーク」）およびプレフィックス長（「プレフィックス」）フィールド。これは、このクライアントに割り当てられたサブネットの内部テーブル内の位置を見つけるためです。次に、サーバーは、このクライアントに割り当てられたサブネットの次のセットに関する情報を提供するサブネット情報サブオプションを含むDHCPOFFERメッセージを返さなければなりません（MUST）。これにより、このクライアントのテーブルのリストが終了した場合、「s」ビットを0に設定して、これ以上情報がないことを示す必要があります。 「c」ビットと「s」ビットの両方を設定せずに検出されたサブネット情報サブオプションは、サーバーによって無視されます。
The actual method of allocating subnets on the DHCP Server, as well as the configuration of what networks may be subnetted and how, is left up to the implementation.
DHCPサーバーでサブネットを割り当てる実際の方法、およびどのネットワークをどのようにサブネット化できるかの構成は、実装次第です。
Only the Subnet Allocation option and accompanying suboptions are displayed in these examples. All other fields in the DHCP messages are described in [RFC2131].
これらの例では、サブネット割り当てオプションと付随するサブオプションのみが表示されています。 DHCPメッセージの他のすべてのフィールドは、[RFC2131]で説明されています。
A DHCP Client requesting a subnet with prefix length 24 from which the Client will allocate addresses to other Clients. The Server responds with an allocation of exactly the size requested:
DHCPクライアントは、プレフィックス長24のサブネットを要求します。このサブネットから、クライアントは他のクライアントにアドレスを割り当てます。サーバーは、要求された正確なサイズの割り当てで応答します。
The Client sends a DHCPDISCOVER message including a Subnet Allocation option with the Subnet-Request suboption:
クライアントは、サブネット割り当てオプションとサブネット割り当てサブオプションを含むDHCPDISCOVERメッセージを送信します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 5 | 0 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 |0|0| 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Server responds with a DHCPOFFER message including a Subnet Allocation option with a Subnet-Information suboption, offering the subnet 10.0.1.0/24.
サーバーは、サブネット情報サブオプションを含むサブネット割り当てオプションを含むDHCPOFFERメッセージで応答し、サブネット10.0.1.0/24を提供します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
The Client sends a DHCPREQUEST including a Subnet Allocation option with a Subnet-Information suboption:
クライアントは、サブネット割り当てオプションとサブネット情報サブオプションを含むDHCPREQUESTを送信します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
The Server responds with a DHCPACK message including a Subnet Allocation option with a Subnet-Information suboption:
サーバーは、サブネット情報サブオプションを含むサブネット割り当てオプションを含むDHCPACKメッセージで応答します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
Later, the Client sends a DHCPRELEASE message including a Subnet Allocation option with a Subnet-Information suboption:
その後、クライアントはサブネット割り当てオプションとサブネット情報サブオプションを含むDHCPRELEASEメッセージを送信します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
A DHCP Client requesting two subnets, each with prefix length 24:
それぞれプレフィックス長が24の2つのサブネットを要求するDHCPクライアント：
The Client sends a DHCPDISCOVER message including a Subnet Allocation option with a Subnet-Request suboption:
クライアントは、サブネット割り当てオプションとサブネット要求サブオプションを含むDHCPDISCOVERメッセージを送信します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 9 | 0 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 |0|0| 24 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 |0|0| 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Server responds with a DHCPOFFER message including a Subnet Allocation option with a Subnet-Information suboption:
サーバーは、サブネット情報オプションとサブネット割り当てオプションを含むDHCPOFFERメッセージで応答します。
The DHCPOFFER specifies one subnet of size 24 and one subnet of size 28.
DHCPOFFERは、サイズ24の1つのサブネットとサイズ28の1つのサブネットを指定します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 18 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 15 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 10 | 0 | 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 28 | |0|0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Client sends a DHCPREQUEST message including a Subnet Allocation option with a Subnet-Information suboption:
クライアントは、サブネット割り当てオプションとサブネット情報サブオプションを含むDHCPREQUESTメッセージを送信します。
The Client decides that the subnet of size 28 is not sufficient so it doesn't include that subnet in the DHCPREQUEST message.
クライアントは、サイズ28のサブネットでは不十分であると判断し、DHCPREQUESTメッセージにそのサブネットを含めません。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
The Server responds with a DHCPACK message including a Subnet
Allocation option with a Subnet-Information suboption:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
Later, the Client sends a DHCPREQUEST message in order to renew the lease on the one subnet and includes subnet usage information. It reports that a maximum of 10 addresses were allocated from the subnet since the last report, 7 addresses are currently allocated, and 2 addresses were found to be unusable.
その後、クライアントはDHCPREQUESTメッセージを送信して、1つのサブネットのリースを更新し、サブネットの使用情報を含めます。前回のレポート以降、サブネットから最大10個のアドレスが割り当てられており、現在7個のアドレスが割り当てられており、2個のアドレスが使用できないことがわかりました。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 17 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 14 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 | 0 | 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Server responds with a DHCPACK message; however, it signals to the Client that the subnet should be deprecated.
サーバーはDHCPACKメッセージで応答します。ただし、サブネットを廃止する必要があることをクライアントに通知します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
The Client reloads at this point and, upon completion of the reload, sends a DHCPDISCOVER asking for information about all subnets that were allocated to it.
この時点でクライアントはリロードし、リロードが完了すると、DHCPDISCOVERを送信して、割り当てられているすべてのサブネットに関する情報を要求します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 5 | 0 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | |1|0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Server responds with a DHCPOFFER, giving the subnet information about the one subnet that is allocated to the Client. Also, the Server specifies that the one allocated subnet should be immediately deprecated. Note that the 's' ("Server") bit is 0, thus indicating that there is no more information available for this Client.
サーバーはDHCPOFFERで応答し、クライアントに割り当てられている1つのサブネットに関するサブネット情報を提供します。また、サーバーは、割り当てられた1つのサブネットを直ちに非推奨にすることを指定しています。 「s」（「サーバー」）ビットは0であることに注意してください。これは、このクライアントで使用できる情報がないことを示しています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | |1|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
The Client responds with a DHCPRELEASE message after having deprecated the subnet:
クライアントは、サブネットを廃止した後、DHCPRELEASEメッセージで応答します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | SIS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
The following differences may be noticed between Subnet Allocation as described in this document and DHCPv6 Prefix Delegation as described in [RFC3633]:
このドキュメントで説明されているサブネット割り当てと、[RFC3633]で説明されているDHCPv6プレフィックス委任との間には、次のような違いがあります。
o This option does not use anything like an "IA_PD" as is used in DHCPv6.
o このオプションでは、DHCPv6で使用されている「IA_PD」のようなものは使用されません。
o If the Server cannot allocate a subnet, it remains silent, instead of returning a special response saying nothing is available.
o サーバーがサブネットを割り当てることができない場合、何も利用できないという特別な応答を返す代わりに、サーバーはサイレントのままです。
o DHCPv6 Prefix Delegation has no mechanism for returning subnet/ prefix usage statistics.
o DHCPv6プレフィックス委任には、サブネット/プレフィックス使用統計を返すメカニズムがありません。
o DHCPv6 has no equivalent to the "subnet deprecation" flag as described here.
o DHCPv6には、ここで説明する「サブネット非推奨」フラグに相当するものはありません。
o DHCPv6 Prefix Delegation makes no mention of what Client actions should result from receiving a DHCPNAK during a RENEW of a delegation.
o DHCPv6プレフィックス委任では、委任のRENEW中にDHCPNAKを受信した結果としてどのクライアントアクションが発生するかについては言及されていません。
o DHCPv6 has no equivalent of the subnet allocation "Network name" suboption, which may be used by the Server for various purposes, such as to specify a pool to use when allocating a subnet.
o DHCPv6には、サブネット割り当ての「ネットワーク名」サブオプションに相当するものはありません。これは、サブネットを割り当てるときに使用するプールを指定するなど、さまざまな目的でサーバーが使用できます。
o DHCPv6 Prefix Delegation corresponds to "Hierarchical Subnet Allocation" (setting the 'h' flag in the Prefix Information block). There is no v6 equivalent of clearing the 'h' flag, in which the Server retains authority over allocation of addresses from the subnet.
o DHCPv6プレフィックス委任は、「階層サブネット割り当て」に対応します（プレフィックス情報ブロックで「h」フラグを設定）。サーバーがサブネットからのアドレスの割り当てに対する権限を保持する「h」フラグをクリアすることに相当するv6はありません。
o DHCPv6 Prefix Delegation has nothing to correspond to the Suggested-Lease-Time suboption.
o DHCPv6プレフィックス委任には、推奨リース時間サブオプションに対応するものはありません。
Potential exposures to attack are discussed in Section 7 of the DHCP protocol specification [RFC2131]. The Subnet Allocation option can be used to hoard all allocable subnets on a network.
攻撃を受ける可能性については、DHCPプロトコル仕様[RFC2131]のセクション7で説明されています。サブネット割り当てオプションを使用すると、ネットワーク上の割り当て可能なすべてのサブネットを保留できます。
Implementations should consider using the DHCP Authentication option [RFC3118] in order to provide a higher level of security if it is deemed necessary in their environment.
実装では、環境で必要と思われる場合に、より高いレベルのセキュリティを提供するために、DHCP認証オプション[RFC3118]の使用を検討する必要があります。
IANA has assigned DHCP option number 220 for this option, in accordance with [RFC3942].
[RFC3942]に従って、IANAはこのオプションにDHCPオプション番号220を割り当てました。
No assignment of values for the suboption codes need be made at this time. New values may only be defined by IETF Consensus, as described in [RFC5226]. Basically, this means that they are defined by RFCs approved by the IESG.
現時点では、サブオプションコードの値を割り当てる必要はありません。 [RFC5226]で説明されているように、新しい値はIETFコンセンサスによってのみ定義できます。基本的に、これは、それらがIESGによって承認されたRFCによって定義されていることを意味します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、1997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張」、RFC 2132、1997年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options", RFC 3942, November 2004.
[RFC3942] Volz、B。、「Reclassifying Dynamic Host Configuration Protocol version 4（DHCPv4）Options」、RFC 3942、2004年11月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118] Droms、R。およびW. Arbaugh、「Authentication for DHCP Messages」、RFC 3118、2001年6月。
[RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP reconfigure extension", RFC 3203, December 2001.
[RFC3203] T'Joens、Y.、Hublet、C。、およびP. De Schrijver、「DHCP reconfigure extension」、RFC 3203、2001年12月。
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.
[RFC3396] Lemon、T。およびS. Cheshire、「Encoding Long Options in the Dynamic Host Configuration Protocol（DHCPv4）」、RFC 3396、2002年11月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633] Troan、O。およびR. Droms、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[RFC4632] Fuller、V。およびT. Li、「Classless Inter-domain Routing（CIDR）：the Internet Address Assignment and Aggregation Plan」、BCP 122、RFC 4632、2006年8月。
The authors gratefully acknowledge the contributions of Jay Kumarasamy.
著者は、Jay Kumarasamyの貢献に感謝します。
Authors' Addresses
著者のアドレス
Richard A. Johnson Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 US
Richard A. Johnson Cisco Systems、Inc. 170 W. Tasman Dr. San Jose、CA 95134 US
Phone: +1 408 526 4000
EMail: raj@cisco.com
Kim Kinnear Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 US
Kim Kinnear Cisco Systems、Inc. 170 W. Tasman Dr. San Jose、CA 95134 US
Phone: +1 408 526 4000
EMail: kkinnear@cisco.com
Mark Stapp Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 US
Mark Stapp Cisco Systems、Inc. 170 W. Tasman Dr. San Jose、CA 95134 US
Phone: +1 408 526 4000
EMail: mjs@cisco.com