[要約] RFC 8947は、DHCPv6を用いてリンク層アドレス（MACアドレス）を動的に割り当てるための拡張仕様を規定しています。大規模な仮想化環境やIoTにおいて、製造時の固定アドレスに頼らず、ドメイン内で重複のないローカルMACアドレスを自動構成する仕組みを提供します。アドレスを管理する「IA_LL」オプションと、アドレスブロックを指定する「LLADDR」オプションを定義し、スケーラブルな管理とリソースの効率的な利用を実現します。
Internet Engineering Task Force (IETF) B. Volz
Request for Comments: 8947 Cisco
Category: Standards Track T. Mrugalski
ISSN: 2070-1721 ISC
CJ. Bernardos
UC3M
December 2020
Link-Layer Address Assignment Mechanism for DHCPv6
DHCPv6のリンク層アドレス割り当てメカニズム
Abstract
概要
In certain environments, e.g., large-scale virtualization deployments, new devices are created in an automated manner. Such devices may have their link-layer addresses assigned in an automated fashion. With sufficient scale, the likelihood of a collision using random assignment without duplication detection is not acceptable. Therefore, an allocation mechanism is required. This document proposes an extension to DHCPv6 that allows a scalable approach to link-layer address assignments where preassigned link-layer address assignments (such as by a manufacturer) are not possible or are unnecessary.
特定の環境では、例えば大規模な仮想化展開では、新しいデバイスが自動化された方法で作成されます。そのような装置は、自動化された方法で割り当てられたリンク層アドレスを有することができる。十分なスケールでは、重複検出なしにランダムな割り当てを使用して衝突の可能性は受け入れられない。したがって、割り当てメカニズムが必要です。この文書は、事前に配置されたリンク層アドレス割り当て（製造業者などによる）が不要であるか不要なリンク層アドレス割り当てへのスケーラブルなアプローチを可能にするDHCPv6への拡張を提案する。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8947.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc8947で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction 2. Requirements Language 3. Terminology 4. Deployment Scenarios 4.1. Scenario: Proxy Client Mode 4.2. Scenario: Direct Client Mode 5. Mechanism Overview 6. Design Assumptions 7. Information Encoding 8. Requesting Addresses 9. Renewing Addresses 10. Releasing Addresses 11. Option Definitions 11.1. Identity Association for Link-Layer Addresses Option 11.2. Link-Layer Addresses Option 12. Selecting Link-Layer Addresses for Assignment to an IA_LL 13. IANA Considerations 14. Security Considerations 15. Privacy Considerations 16. References 16.1. Normative References 16.2. Informative References Appendix A. IEEE 802c Summary Acknowledgments Authors' Addresses
There are several deployment types that deal with a large number of devices that need to be initialized. One of them is a scenario where virtual machines (VMs) are created on a massive scale. Typically, the new VM instances are assigned a link-layer address, but random assignment does not scale well due to the risk of a collision (see Appendix A.1 of [RFC4429]). Another use case is Internet of Things (IoT) devices (see [RFC7228]). The huge number of such devices could strain the IEEE's available Organizationally Unique Identifier (OUI) global address space. While there is typically no need to provide global link-layer address uniqueness for such devices, a link-layer assignment mechanism allows for conflicts to be avoided inside an administrative domain. For those reasons, it is desired to have some form of mechanism that would be able to assign locally unique Media Access Control (MAC) addresses.
初期化する必要がある多数のデバイスを扱う展開タイプがいくつかあります。そのうちの1つは、仮想マシン（VM）が大規模に作成されているシナリオです。通常、新しいVMインスタンスにはリンク層アドレスが割り当てられていますが、ランダムな割り当ては衝突の危険性があるためによくスケールされません（[RFC4429]の付録A.1を参照）。別のユースケースは、インターネット（IoT）デバイスです（[RFC7228]を参照）。そのようなデバイスの膨大な数は、IEEEの組織的に一意の識別子（OUI）グローバルアドレス空間を歪むことができます。そのようなデバイスに対してグローバルなリンク層アドレスの一意性を提供する必要がないが、リンク層割り当てメカニズムは管理ドメイン内で競合を回避することを可能にする。これらの理由から、ローカルに固有のメディアアクセス制御（MAC）アドレスを割り当てることができるかどうかのメカニズムを何らかの形式であることが望ましい。
This document proposes a new mechanism that extends DHCPv6 operation to handle link-layer address assignments.
この文書は、リンク層のアドレス割り当てを処理するためにDHCPv6操作を拡張する新しいメカニズムを提案します。
Since DHCPv6 [RFC8415] is a protocol that can allocate various types of resources (non-temporary addresses, temporary addresses, prefixes, as well as many options) and has the necessary infrastructure to maintain such allocations (numerous server and client implementations, large deployed relay infrastructure, and supportive solutions such as leasequery and failover), it is a good candidate to address the desired functionality.
DHCPv6 [RFC8415]は、さまざまな種類のリソースを割り当てることができるプロトコル（一時的なアドレス以外のアドレス、一時アドレス、プレフィックス、および多くのオプション）で、そのような割り当てを維持するために必要なインフラストラクチャを持っています（多数のサーバーとクライアントの実装、大規模な展開リレーインフラストラクチャ、およびリースクエリやフェイルオーバーなどのサポート解決策は、希望の機能に対処するのは良い候補です。
While this document presents a design that should be usable for any link-layer address type, some of the details are specific to IEEE 802 48-bit MAC addresses [IEEEStd802]. Future documents may provide specifics for other link-layer address types.
このドキュメントでは、リンクレイヤアドレスタイプに使用できるデザインが表示されますが、詳細はIEEE 802 48ビットMACアドレス[IEEESTD802]に固有のものです。将来の文書は、他のリンク層アドレスタイプの詳細を提供することがあります。
IEEE 802 originally set aside half of the 48-bit MAC address space for local use (where the Universal/Local (U/L) bit is set to 1). In 2017, IEEE published an amendment [IEEEStd802c] that divides this space into quadrants with differentiated address rules. More details are in Appendix A.
IEEE 802は、ローカル使用のために48ビットMACアドレス空間の半分を扱う（Univeral / Local（U/L）ビットが1に設定されている場合）。2017年、IEEEは、このスペースを区別されたアドレス規則の象限に分割する修正[IEEESTD802C]を発表しました。詳細は付録Aに記載されています。
IEEE is also developing protocols and procedures for assignment of locally unique addresses (IEEE 802.1CQ). This work may serve as an alternative protocol for assignment. For additional background, see [IEEE-P802.1CQ-Project].
IEEEは、ローカルに固有のアドレスを割り当てるためのプロトコルと手順も開発しています（IEEE 802.1CQ）。この作業は、割り当ての代替プロトコルとして機能することがあります。その他の背景については、[IEEE-P802.1CQ-PROJECT]を参照してください。
The DHCP terminology relevant to this specification from [RFC8415] applies here. The following definitions either modify those definitions as to how they are used in this document or define new terminology used herein.
[RFC8415]からこの仕様に関連するDHCPの用語はここに適用されます。以下の定義は、この文書でどのように使用されているか、または本明細書で使用される新しい用語を定義する方法についての定義を変更します。
address Unless specified otherwise, a link-layer (or MAC) address, as specified in [IEEEStd802]. The address is typically six octets long, but some network architectures may use different lengths.
特記しない限り、[IEEESTD802]で指定されているリンクレイヤ（またはMAC）アドレス。アドレスは通常6オクテットの長さですが、一部のネットワークアーキテクチャは異なる長さを使用できます。
address block A number of consecutive link-layer addresses. An address block is expressed as a first address plus a number that designates the number of additional (extra) addresses. A single address can be represented by the address itself and zero extra addresses.
アドレスは、連続したリンク層アドレスの数をブロックします。アドレスブロックは、追加のアドレスと追加の（追加）アドレスの数を指定する数字として表現されます。単一のアドレスは、アドレス自体と追加アドレスゼロで表すことができます。
client A node that is interested in obtaining link-layer addresses. It implements the basic DHCP mechanisms needed by a DHCP client, as described in [RFC8415], and supports the new options specified in this document (IA_LL and LLADDR). The client may or may not support IPv6 address assignment and prefix delegation, as specified in [RFC8415].
IA_LL Identity Association for Link-Layer Address, an identity association (IA) used to request or assign link-layer addresses. See Section 11.1 for details on the IA_LL option.
リンク層アドレス、リンク層アドレスを要求または割り当てるために使用されるIDLEDアドレスのIA_LL ID関連付け。IA_LLオプションの詳細については11.1項を参照してください。
LLADDR Link-layer address option that is used to request or assign a block of link-layer addresses. See Section 11.2 for details on the LLADDR option.
LLADDRリンク層アドレスを要求または割り当てるために使用されるオプション。LLADDRオプションの詳細については11.2項を参照してください。
server A node that manages link-layer address allocation and is able to respond to client queries. It implements basic DHCP server functionality, as described in [RFC8415], and supports the new options specified in this document (IA_LL and LLADDR). The server may or may not support IPv6 address assignment and prefix delegation as specified in [RFC8415].
This mechanism is designed to be generic and usable in many deployments, but there are two scenarios it attempts to address in particular: (i) proxy client mode and (ii) direct client mode.
このメカニズムは一般的であるように設計されており、多くの展開で使用可能になるように設計されていますが、特に対処しようとする2つのシナリオがあります。（i）プロキシクライアントモードと（ii）直接クライアントモード。
This mode is used when an entity acts as a DHCP client that requests that available DHCP servers assign one or more addresses (an address block) for the DHCP client to then assign to the final end devices to use. Large-scale virtualization is one application scenario for proxy client mode. In such environments, this entity is often called a "hypervisor" and is frequently required to spawn new VMs. The hypervisor needs to assign new addresses to those machines. The hypervisor does not use those addresses for itself, but rather it uses them to create new VMs with appropriate addresses. It is worth pointing out the cumulative nature of this scenario. Over time, the hypervisor is likely to increase its address use. Some obsolete VMs will be deleted; their addresses are potentially eligible for reuse by new VMs.
このモードは、使用可能なDHCPサーバーがDHCPクライアントの1つ以上のアドレス（アドレスブロック）を割り当てて、使用する最終エンドデバイスに割り当てることを要求するDHCPクライアントとして機能する場合に使用されます。大規模仮想化は、プロキシクライアントモードの1つのアプリケーションシナリオです。そのような環境では、このエンティティはしばしば「ハイパーバイザー」と呼ばれ、新しいVMSを出現するために頻繁に必要です。ハイパーバイザーはそれらのマシンに新しいアドレスを割り当てる必要があります。ハイパーバイザーはそれらのアドレスをそれ自体で使用しませんが、それらを使用して適切なアドレスを持つ新しいVMを作成します。このシナリオの累積的な性質を指摘する価値があります。時間が経つにつれて、ハイパーバイザーはそのアドレス使用を増やす可能性があります。いくつかの時代遅れのVMは削除されます。彼らの住所は、新しいVMSによる再利用の対象となります。
This mode can be used when an entity acts as a DHCP client that requests that available DHCP servers assign one or more addresses (an address block) for its own use. This usage scenario is related to IoT (see Section 1). Upon first boot, for each interface, the device uses a temporary address, as described in [IEEEStd802.11] and IEEE 802.1CQ [IEEE-P802.1CQ-Project], to send initial DHCP packets to available DHCP servers wherein the device requests a single address for that network interface. Once the server assigns an address, the device abandons its temporary address and uses the assigned (leased) address.
このモードは、エンティティが利用可能なDHCPサーバがそれ自身の使用のために1つ以上のアドレス（アドレスブロック）を割り当てることを要求するDHCPクライアントとして機能するときに使用できます。この使用状況シナリオはIoTに関連しています（セクション1を参照）。最初の起動時に、各インターフェイスについて、[IEEESTD802.11]およびIEEE 802.1CQ [IEEE-P802.1CQ-PROJECT]で説明されているように、デバイスがリクエストされたDHCPサーバーに最初のDHCPパケットを送信するように一時アドレスを使用します。そのネットワークインターフェイスの単一のアドレス。サーバーがアドレスを割り当てたら、デバイスはその一時アドレスに搭載され、割り当てられた（リース）アドレスを使用します。
Note that a client that operates as above that does not have a globally unique link-layer address on any of its interfaces MUST NOT use a link-layer-based DHCP Unique Identifier (DUID). For more details, refer to Section 11 of [RFC8415].
上記のように動作するクライアントは、そのインタフェースの任意のインターフェイス上にグローバルに固有のリンク層アドレスを持たないクライアントが、リンクレイヤベースのDHCP固有ID（DUID）を使用してはいけません (MUST NOT)。詳細については、[RFC8415]のセクション11を参照してください。
Also, a client that operates as above may run into issues if the switch it is connected to prohibits or restricts link-layer address changes. This may limit where this capability can be used or may require the administrator to adjust the configuration of the switch(es) to allow a change in address.
また、上記のように動作するクライアントは、リンク層アドレスの変更を禁止または制限するように接続されている場合には問題が発生する可能性があります。これは、この機能が使用できる場所を制限するか、アドレスの変更を許可するためにスイッチの構成を調整するために管理者にスイッチの構成を調整する必要があるかもしれません。
In the scenarios described in Section 4, the protocol operates in fundamentally the same way. The device requesting an address, acting as a DHCP client, will send a Solicit message with an IA_LL option to all available DHCP servers. That IA_LL option MUST include an LLADDR option specifying the link-layer-type and link-layer-len, and it may include a specific address or address block as a hint for the server. Each available server responds with either a Reply message with committed address(es) (if Rapid Commit was requested and honored) or an Advertise message with offered address(es). The client selects a server's response, as governed by [RFC8415]. If necessary, the client sends a Request message; the target server will then assign the address(es) and send a Reply message. Once a Reply is received, the client can start using those address(es).
セクション4で説明するシナリオでは、プロトコルは基本的に同じ方法で動作します。DHCPクライアントとして動作する、アドレスを要求する機器は、利用可能なすべてのDHCPサーバーにIA_LLオプションを含むSolicitメッセージを送信します。そのIA_LLオプションは、link-layer-typeとlink-layer-lenを指定するLLADDRオプションを含まなければならず (MUST)、サーバーへのヒントとして特定のアドレスやアドレスブロックを含めることもできます。利用可能な各サーバーは、確定したアドレスを含むReplyメッセージ（Rapid Commitが要求され、それが受け入れられた場合）か、提示するアドレスを含むAdvertiseメッセージで応答します。クライアントは、[RFC8415]の規定に従ってサーバーの応答を選択します。必要な場合、クライアントはRequestメッセージを送信し、対象のサーバーはアドレスを割り当ててReplyメッセージを送信します。Replyを受信すると、クライアントはそれらのアドレスの使用を開始できます。
Normal DHCP mechanisms are in use. The client is expected to periodically renew the addresses as governed by T1 and T2 timers and to stop using the address once the valid lifetime expires. Renewals can be administratively disabled by the server sending "infinity" as the T1 and T2 values (see Section 7.7 of [RFC8415]). An administrator may make the address assignment permanent by specifying use of the "infinity" valid lifetime, as defined in Section 7.7 of [RFC8415].
The client can release addresses when they are no longer needed by sending a Release message (see Section 18.2.7 of [RFC8415]).
クライアントは、リリースメッセージを送信することによって不要になったときにアドレスを解放することができます（[RFC8415]のセクション18.2.7を参照）。
Figure 9 in [RFC8415] shows a timeline diagram of the messages exchanged between a client and two servers for the typical life cycle of one or more leases.
[RFC8415]の図9は、1つ以上のリースの典型的なライフサイクルのためにクライアントと2つのサーバー間で交換されたメッセージのタイムライン図を示しています。
Confirm and Information-request messages are not used in link-layer address assignment. Decline should technically never be needed, but see Section 12 for one situation where this message is needed.
リクエストメッセージの確認と情報要求メッセージは、リンクレイヤアドレス割り当てでは使用されません。辞退は技術的には必要とされるべきではなく、このメッセージが必要な場合はセクション12を参照してください。
Clients implementing this mechanism SHOULD use the Rapid Commit option, as specified in Sections 5.1 and 18.2.1 of [RFC8415], to obtain addresses with a two-message exchange when possible.
このメカニズムを実装するクライアントは、可能であれば2メッセージ交換でアドレスを取得するために、[RFC8415]のセクション5.1および18.2.1で指定されているRapid Commitオプションを使用すべきです (SHOULD)。
Devices supporting this proposal MAY support the reconfigure mechanism, as defined in Section 18.2.11 of [RFC8415]. If supported by both server and client, the reconfigure mechanism allows the administrator to immediately notify clients that the configuration has changed and triggers retrieval of relevant changes immediately, rather than after the T1 timer elapses. Since this mechanism requires implementation of Reconfiguration Key Authentication Protocol (see Section 20.4 of [RFC8415]), small-footprint devices may choose not to support it.
One of the essential aspects of this mechanism is its cumulative nature, especially in the hypervisor scenario. The server-client relationship does not look like other DHCP transactions in the hypervisor scenario. In a typical environment, there would be one server and a rather small number of hypervisors, possibly even only one. However, over time, the number of addresses requested by the hypervisor(s) will increase as more VMs are spawned.
このメカニズムの本質的な側面の1つは、特にハイパーバイザーシナリオでの累積的な性質です。サーバークライアントの関係は、ハイパーバイザーシナリオの他のDHCPトランザクションのようには見えません。典型的な環境では、1つのサーバーとかなり少数のハイパーバイザー、おそらくただ1つだけです。ただし、時間の経過とともに、Hypervisorによって要求されたアドレスの数は、より多くのVMが生成されるにつれて増加します。
Another aspect crucial for efficient design is the observation that a single client acting as hypervisor will likely use thousands of addresses. An approach similar to what is used for IPv6 address or prefix assignment (IA container with all assigned addresses listed, one option for each address) would not work well. Therefore, the mechanism should operate on address blocks rather than single values. A single address can be treated as an address block with just one address.
効率的な設計にとって非常に重要な別の側面は、ハイパーバイザーとして機能する単一のクライアントが何千ものアドレスを使用する可能性が高いという観察です。IPv6アドレスまたはプレフィックス割り当てに使用されるものと同様の方法（IAコンテナがリストされているすべてのアドレスの1つのオプション）はうまく機能しません。したがって、メカニズムは単一の値ではなくアドレスブロックを操作する必要があります。単一のアドレスはアドレスブロックとして1つのアドレスブロックとして扱うことができます。
The DHCP mechanisms are reused to a large degree, including message and option formats, transmission mechanisms, relay infrastructure, and others. However, a device wishing to support only link-layer address assignment is not required to support full DHCP. In other words, the device may support only assignment of link-layer addresses but not IPv6 addresses or prefixes.
DHCPメカニズムは、メッセージとオプションフォーマット、送信メカニズム、リレーインフラストラクチャなどを含む大きな程度に再利用されます。しかしながら、リンク層アドレス割り当てのみをサポートすることを望む装置は、完全なDHCPをサポートするために必要とされない。言い換えれば、装置は、リンク層アドレスの割り当てのみをサポートしていても、IPv6アドレスまたはプレフィックスではない。
A client MUST send an LLADDR option encapsulated in an IA_LL option to specify the link-layer-type and link-layer-len values. For link-layer-type 1 (Ethernet) and 6 (IEEE 802 Networks), a client sets the link-layer-address field to:
クライアントは、リンクレイヤタイプとリンク層-LEN値を指定するために、IA_LLオプションにカプセル化されたLLADDRオプションを送信しなければなりません (MUST)。Link-Layer-Type 1（Ethernet）および6（IEEE 802ネットワーク）の場合、クライアントはリンクレイヤアドレスフィールドを次のように設定します。
1. All zeroes if the client has no hint as to the starting address of the unicast address block. This address has the IEEE 802 individual/group bit set to 0 (individual).
1. クライアントがユニキャストアドレスブロックの開始アドレスに関してヒントがない場合、すべてのゼロ。このアドレスには、0（個別）にIEEE 802個別/グループビットが設定されています。
2. Any other value to request a specific block of address starting with the specified address.
2. 指定されたアドレスから始まる特定のアドレスブロックを要求するためのその他の値。
Encoding information for other link-layer-types may be added in the future by publishing an RFC that specifies those values.
これらの値を指定するRFCを公開することによって、他のリンクレイヤタイプのエンコード情報が将来追加されることがあります。
A client sets the extra-addresses field to either 0 for a single address or the size of the requested address block minus 1.
クライアントは、1つのアドレスまたは要求されたアドレスブロックマイナス1のサイズに対して0のいずれかのアドレスフィールドを0に設定します。
A client MUST set the valid-lifetime field to 0 (this field MUST be ignored by the server).
クライアントは有効な有効期間フィールドを0に設定しなければなりません (MUST)（このフィールドはサーバーによって無視されなければなりません (MUST)）。
The addresses are assigned in blocks. The smallest block is a single address. To request an assignment, the client sends a Solicit message with an IA_LL option inside. The IA_LL option MUST contain an LLADDR option, as specified in Section 7.
アドレスはブロックで割り当てられます。最小ブロックは単一のアドレスです。割り当てを要求するために、クライアントはIA_LLオプションを内部に求めるメッセージを送信します。IA_LLオプションは、セクション7で指定されているように、LLADDRオプションを含めなければなりません (MUST)。
The server, upon receiving an IA_LL option, inspects its content and may offer an address or addresses for each LLADDR option according to its policy. The server MAY take into consideration the address block requested by the client in the LLADDR option. However, the server MAY choose to ignore some or all parameters of the requested address block. In particular, the server may send either a different starting address or a smaller number of addresses than requested. The server sends back an Advertise message with an IA_LL option containing an LLADDR option that specifies the addresses being offered. If the server is unable to provide any addresses, it MUST return the IA_LL option containing a Status Code option (see Section 21.13 of [RFC8415]) with status set to NoAddrsAvail.
サーバーは、IA_LLオプションを受信したときに、そのコンテンツを検査し、そのポリシーに従って各LLADDRオプションのアドレスまたはアドレスを提供することができます。サーバーは、LLADDRオプションでクライアントによって要求されたアドレスブロックを考慮に入れることがあります (MAY)。ただし、サーバーは、要求されたアドレスブロックの一部またはすべてのパラメータを無視することを選択できます (MAY)。特に、サーバは、要求されたよりも少ない開始アドレスまたはより少ない数のアドレスを送信することができる。サーバーは、提供されているアドレスを指定するLLADDRオプションを含むIA_LLオプションを含むアドバタイズメッセージを送ります。サーバーがアドレスを提供できない場合は、ステータスコードオプションを含むIA_LLオプションを返さなければなりません (MUST)（[RFC8415]のセクション21.13）NoAddrsAvailに設定されています。
Note that servers that do not support the IA_LL option will ignore the option and not return it in Advertise (and Reply) messages. Clients that send IA_LL options MUST treat this as if the server returned the NoAddrsAvail status for these IA_LL option(s).
IA_LLオプションをサポートしていないサーバーはオプションを無視し、それをアドバタイズ（および返信）メッセージに返さないでください。IA_LLオプションを送信するクライアントは、サーバーがこれらのIA_LLオプションのNoAddrsAvailステータスを返したかのようにこれを扱わなければなりません (MUST)。
The client waits for available servers to send Advertise responses and picks one server, as defined in Section 18.2.9 of [RFC8415]. The client then sends a Request message that includes the IA_LL container option with the LLADDR option copied from the Advertise message sent by the chosen server.
クライアントは、[RFC8415]のセクション18.2.9で定義されているように、Advertise Responsesを送信し、1つのサーバーを選択するのを待ちます。その後、クライアントは、選択されたサーバーによって送信されたアドバタイズメッセージからコピーされたLLADDRオプションを含むIA_LLコンテナオプションを含む要求メッセージを送信します。
The client MUST process the address block(s) returned in the Advertise, rather than what it included in the Solicit message, and may consider the offered address block(s) in selecting the Advertise message to accept. The server may offer a smaller number of addresses or different addresses from those requested. A client MUST NOT use resources returned in an Advertise message except to select a server and in sending the Request message to that server; resources are only useable by a client when returned in a Reply message.
クライアントは、それが勧誘メッセージに含まれているものではなく、アドレスブロックをアドレスブロックを処理しなければならず (MUST)、その宣伝メッセージを選択するための提供されたアドレスブロックを検討することができます。サーバは、要求されたものから、より少ない数のアドレスまたは異なるアドレスを提供することができる。クライアントは、サーバーを選択したり、そのサーバーに要求メッセージを送信するのを除いて、アドバタイズメッセージで返されたリソースを使用してはなりません (MUST NOT)。リソースは、返信メッセージで返されたときにのみ使用可能です。
Upon reception of a Request message with the IA_LL container option, the server assigns the requested addresses. The server allocates a block of addresses according to its configured policy. The server MAY assign a different block or smaller block size than requested in the Request message. The server then generates and sends a Reply message back to the client.
IA_LLコンテナオプションを含むRequestメッセージを受信すると、サーバーは要求されたアドレスを割り当てます。サーバーは設定されたポリシーに従ってアドレスブロックを割り当てます。サーバーは、Requestメッセージで要求されたものとは異なるブロック、またはより小さなブロックサイズを割り当ててもよい (MAY)。その後、サーバーはReplyメッセージを生成してクライアントに返送します。
Upon receiving a Reply message, the client parses the IA_LL container option and may start using all provided addresses. It MUST restart its T1 and T2 timers using the values specified in the IA_LL option.
返信メッセージを受信すると、クライアントはIA_LLコンテナオプションを解析し、提供されているすべてのアドレスを使用して開始されます。IA_LLオプションで指定された値を使用してT1およびT2タイマを再起動しなければなりません (MUST)。
The client MUST use the address block(s) returned in the Reply message, which may be a smaller block(s) or may have a different address(es) than requested.
クライアントは、Replyメッセージで返されたアドレスブロックを使用しなければなりません (MUST)。それは要求したものより小さいブロックであったり、要求したものとは異なるアドレスであったりする場合があります。
A client that has included a Rapid Commit option in the Solicit message may receive a Reply in response to the Solicit message and skip the Advertise and Request message steps above (see Section 18.2.1 of [RFC8415]).
閲覧メッセージにRapid Commitオプションを含めたクライアントは、募集メッセージに応答して返信を受け取り、上記のアドバタイズおよび要求の手順をスキップすることができます（[RFC8415]のセクション18.2.1参照）。
A client that changes its link-layer address on an interface SHOULD follow the recommendations in Section 7.2.6 of [RFC4861] to inform its neighbors of the new link-layer address quickly.
インターフェイス上のリンクレイヤアドレスを変更するクライアントは、[RFC4861]のセクション7.2.6の推奨事項に従って、新しいリンク層アドレスの隣接者に迅速に通知すべきです (SHOULD)。
Address renewals follow the normal DHCP renewals processing described in Section 18.2.4 of [RFC8415]. Once the T1 timer elapses, the client starts sending Renew messages with the IA_LL option containing an LLADDR option for the address block being renewed. The server responds with a Reply message that contains the renewed address block. The server MUST NOT shrink or expand the address block. Once a block is assigned and has a non-zero valid lifetime, its size, starting address, and ending address MUST NOT change.
アドレス更新[RFC8415]のセクション18.2.4で説明されている通常のDHCP更新処理に従ってください。T1タイマが経過すると、クライアントは更新されているアドレスブロックのLLADDRオプションを含むIA_LLオプションを使用して更新メッセージの送信を開始します。サーバーは、更新されたアドレスブロックを含む返信メッセージで応答します。サーバーはアドレスブロックを縮小または拡張してはいけません (MUST NOT)。ブロックが割り当てられ、ゼロ以外の有効な有効期間、そのサイズ、開始アドレス、および終了アドレスが変更されてはいけません (MUST NOT)。
If the requesting client needs additional addresses (e.g., in the hypervisor scenario because addresses need to be assigned to new VMs), it MUST send an IA_LL option with a different Identity Association IDentifier (IAID) to create another "container" for more addresses.
要求元のクライアントが追加のアドレスを必要とする場合（例：ハイパーバイザーのシナリオで新しいVMにアドレスを割り当てる必要がある場合）、より多くのアドレスのための別の「コンテナー」を作成するため、異なるIdentity Association IDentifier（IAID）を持つIA_LLオプションを送信しなければなりません (MUST)。
If the client is unable to renew before the T2 timer elapses, it starts sending Rebind messages, as described in Section 18.2.5 of [RFC8415].
T2タイマが経過する前にクライアントが更新できない場合は、[RFC8415]のセクション18.2.5で説明されているように、リファインドメッセージの送信を開始します。
The client may decide to release a leased address block. A client MUST release the block in its entirety. A client releases an address block by sending a Release message that includes an IA_LL option containing the LLADDR option for the address block to release. The Release transmission mechanism is described in Section 18.2.7 of [RFC8415].
クライアントは、リースアドレスブロックを解放することを決定することができます。クライアントはその全体がブロックを解放しなければなりません (MUST)。クライアントは、アドレスブロックのLLADDRオプションを含むIA_LLオプションを含むリリースメッセージを送信することによってアドレスブロックを解放する。解放伝送機構は[RFC8415]の第18.2.7項に記載されている。
Note that if the client is releasing the link-layer address it is using, it MUST stop using this address before sending the Release message (as per [RFC8415]). In order to send the Release message, the client MUST use another address (such as the one originally used to initiate DHCPv6 to provide an allocated link-layer address).
クライアントが使用しているリンクレイヤアドレスを使用している場合は、リリースメッセージを送信する前にこのアドレスを使用するのを停止しなければなりません (MUST)（[RFC8415]）。リリースメッセージを送信するためには、クライアントは別のアドレスを使用しなければならない (MUST)（もともとDHCPv6を開始して割り当てられたリンク層アドレスを提供するために）。
This mechanism uses an approach similar to the existing mechanisms in DHCP. There is one container option (the IA_LL option) that contains the actual address or addresses, represented by an LLADDR option. Each LLADDR option represents an address block, which is expressed as a first address with a number that specifies how many additional addresses are included.
このメカニズムは、DHCPの既存のメカニズムと同様の方法を使用します。LLADDRオプションで表される、実際のアドレスまたはアドレスを含むコンテナオプション（IA_LLオプション）が1つあります。各LLADDRオプションはアドレスブロックを表します。これは、追加のアドレスが含まれている数字を指定した最初のアドレスとして表されます。
The Identity Association for Link-Layer Addresses option (the IA_LL option) is used to carry an IA_LL, the parameters associated with the IA_LL, and the address blocks associated with the IA_LL.
リンク層アドレスオプション（IA_LLオプション）のID関連付け（IA_LLオプション）は、IA_LL、IA_LLに関連付けられているパラメータ、およびIA_LLに関連付けられているアドレスブロックを伝送するために使用されます。
The format of the IA_LL option is:
IA_LLオプションの形式は次のとおりです。
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_LL | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IA_LL-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IA_LL Option Format
図1：IA_LLオプションフォーマット
option-code OPTION_IA_LL (138).
オプションコードOPTION_IA_LL（138）。
option-len 12 + length of IA_LL-options field.
Option-Len 12 IA_LL-optionsフィールドの長さ。
IAID The unique identifier for this IA_LL; the IAID must be unique among the identifiers for all of this client's IA_LLs. The number space for IA_LL IAIDs is separate from the number space for other IA option types (i.e., IA_NA, IA_TA, and IA_PD). A 4-octet field containing an unsigned integer.
このIA_LLのためのユニークな識別子。IAIDは、このクライアントのすべてのIA_LLの識別子間で一意でなければなりません。IA_LL IAIDの数スペースは、他のIAオプションタイプの数スペースとは別のものとは別のIAオプションタイプ（すなわち、IA_NA、IA_TA、およびIA_PD）です。符号なし整数を含む4オクテットフィールド。
T1 The time interval after which the client should contact the server from which the addresses in the IA_LL were obtained to extend the valid lifetime of the addresses assigned to the IA_LL; T1 is a time duration relative to the current time expressed in units of seconds. A 4-octet field containing an unsigned integer.
T1クライアントがIA_LLに割り当てられているアドレスの有効な有効期間を延長するために、クライアントがIA_LL内のアドレスが取得されたサーバーに連絡する時間間隔。T1は、秒単位で表される現在時刻に対する持続時間です。符号なし整数を含む4オクテットフィールド。
T2 The time interval after which the client should contact any available server to extend the valid lifetime of the addresses assigned to the IA_LL; T2 is a time duration relative to the current time expressed in units of seconds. A 4-octet field containing an unsigned integer.
T2クライアントが任意のサーバーに連絡する時間間隔は、IA_LLに割り当てられているアドレスの有効な有効期間を拡張するために。T2は、秒単位で表される現在時刻に対する期間です。符号なし整数を含む4オクテットフィールド。
IA_LL-options Options associated with this IA_LL. A variable-length field (12 octets less than the value in the option-len field).
IA_LL - このIA_LLに関連したオプション。可変長フィールド（オプション-LENフィールドの値よりも12オクテット）。
An IA_LL option may only appear in the options area of a DHCP message. A DHCP message may contain multiple IA_LL options (though each must have a unique IAID).
IA_LLオプションは、DHCPメッセージのオプション領域にのみ表示されます。DHCPメッセージには、複数のIA_LLオプションが含まれている可能性があります（それぞれは独自のIAIDを持っていなければなりません）。
The status of any operations involving this IA_LL is indicated in a Status Code option (see Section 21.13 of [RFC8415]) in the IA_LL-options field.
このIA_LLを含む操作の状況は、IA_LL-optionsフィールドのステータスコードオプション（[RFC8415]のセクション21.13を参照）に表示されます。
Note that an IA_LL has no explicit "lifetime" or "lease length" of its own. When the valid lifetimes of all of the addresses in an IA_LL have expired, the IA_LL can be considered to be expired. T1 and T2 are included to give servers explicit control over when a client recontacts the server about a specific IA_LL.
IA_LLには、独自の明示的な「有効期間」または「リース長」がないことに注意してください。IA_LL内のすべてのアドレスの有効な寿命が期限切れになった場合、IA_LLは期限切れと見なすことができます。T1とT2は、クライアントが特定のIA_LLに関するサーバーを再接続するときにサーバーを明示的に制御するために含まれています。
In a message sent by a client to a server, the T1 and T2 fields MUST be set to 0. The server MUST ignore any values in these fields in messages received from a client.
クライアントからサーバーに送信されたメッセージでは、T1フィールドとT2フィールドは0に設定しなければなりません (MUST)。サーバーは、クライアントから受信したメッセージ内のこれらのフィールドの値を無視しなければなりません (MUST)。
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 times, 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.
サーバーからクライアントに送信されたメッセージにおいて、T1フィールドとT2フィールドの値が0でない限り、クライアントはT1とT2の時間としてそれらのフィールドの値を使用しなければなりません (MUST)。T1フィールドとT2フィールドの値は、T1とT2までの秒数です。
As per Section 7.7 of [RFC8415], the value 0xffffffff is taken to mean "infinity" and should be used carefully.
[RFC8415]のセクション7.7によると、0xFFFFFFFFは「無限大」を意味し、慎重に使用する必要があります。
The server selects the T1 and T2 times to allow the client to extend the lifetimes of any address block in the IA_LL 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 valid lifetime of the address blocks in the IA that the server is willing to extend, respectively. If the "shortest" valid lifetime is 0xffffffff ("infinity"), the recommended T1 and T2 values are also 0xffffffff. If the time at which the addresses in an IA_LL are to be renewed is to be left to the discretion of the client, the server sets T1 and T2 to 0. The client MUST follow the rules defined in Section 14.2 of [RFC8415].
サーバーは、サーバーが何らかの短時間で使用できなくても、ライフタイムが期限切れになっていても、ライフタイムが期限切れになっていても、Lifetimesが期限切れになる前にクライアントがIA_LL内の任意のアドレスブロックの寿命を延長できるようにT1とT2回を選択します。T1およびT2の推奨値は、それぞれサーバーが維持されていることを望んでいるIA内のアドレスブロックの最短有効な有効期間です。「最短」有効な有効期間が0xFFFFFFFF（ "Infinity"）の場合、推奨されるT1とT2の値も0xFFFFFFFFです。IA_LL内のアドレスが更新される時間がクライアントの裁量に残される場合、サーバーはT1とT2を0に設定します。クライアントは[RFC8415]のセクション14.2で定義されている規則に従わなければなりません (MUST)。
If a client receives an IA_LL with T1 greater than T2, and both T1 and T2 are greater than 0, the client discards the IA_LL option and processes the remainder of the message as though the server had not included the invalid IA_LL option.
クライアントがT1よりも大きいIA_LLを受信し、T1とT2の両方が0より大きい場合、クライアントはIA_LLオプションを破棄し、サーバーが無効なIA_LLオプションを含めていないかのようにメッセージの残りの部分を処理します。
The IA_LL-options field typically contains one or more LLADDR options (see Section 11.2). If a client does not include an LLADDR option in a Solicit or Request message, the server MUST treat this as a request for a single address and that the client has no hint as to the address it would like.
IA_LL-optionsフィールドには通常、1つ以上のLLADDRオプションが含まれています（セクション11.2を参照）。クライアントに任意または要求メッセージにLLADDRオプションが含まれていない場合、サーバーはこれを単一のアドレスの要求として扱い、クライアントにアドレスに関してヒントがないことが必要です。
The Link-Layer Addresses option is used to specify an address block associated with an IA_LL. The option must be encapsulated in the IA_LL-options field of an IA_LL option. The LLaddr-options field encapsulates those options that are specific to this address block.
リンク層アドレスオプションは、IA_LLに関連付けられているアドレスブロックを指定するために使用されます。このオプションは、IA_LLオプションのIA_LL-optionsフィールドにカプセル化する必要があります。lladdr-optionsフィールドは、このアドレスブロックに固有のオプションをカプセル化します。
The format of the Link-Layer Addresses 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_LLADDR | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| link-layer-type | link-layer-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. link-layer-address .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extra-addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. LLaddr-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: LLADDR Option Format
図2：LLADDRオプションフォーマット
option-code OPTION_LLADDR (139).
オプションコードOPTION_LLADDR（139）。
option-len 12 + link-layer-len field value + length of LLaddr-options field. Assuming a link-layer-address length of 6 and no extra options, the option-len would be 18.
Option-Len 12 Lind-Layer-Lenフィールド値lladdr-optionsフィールドの値。リンクレイヤアドレス長さ6と追加のオプションがないと仮定すると、オプションLENは18になります。
link-layer-type The link-layer type MUST be a valid hardware type assigned by IANA, as described in [RFC5494], and registered in the "Hardware Types" registry at <https://www.iana.org/assignments/arp-parameters>. A 2-octet field containing an unsigned integer.
link-layer型リンクレイヤタイプは、[RFC5494]で説明されているように、IANAによって割り当てられた有効なハードウェアタイプでなければなりません (MUST)。<https://www.iana.org/assignments/arp-parameters>。符号なし整数を含む2オクテットフィールド。
link-layer-len Specifies the length, in octets, of the link-layer-address field (typically 6 for a link-layer-type of 1 (Ethernet) and 6 (IEEE 802 Networks)). This is to accommodate link layers that may have variable-length addresses. A 2-octet field containing an unsigned integer.
link-layer-lenは、Link-Layer-Addressフィールドの長さを、Link-Layer-Addressフィールドの長さ（通常は1（イーサネット（イーサネット）と6（IEEE 802ネットワーク））を指定します。これは、可変長アドレスを持つことができるリンク層を収容することです。符号なし整数を含む2オクテットフィールド。
link-layer-address Specifies the address of the first link-layer address that is being requested or assigned depending on the message. A client MAY send a special value to request any address. For link-layer types 1 and 6, see Section 7 for details on this field. A link-layer-len length octet field containing an address.
link-layer-addressメッセージに応じて要求または割り当てられている最初のリンク層アドレスのアドレスを指定します。クライアントはアドレスを要求するための特別な値を送信することができます (MAY)。リンク層タイプ1と6については、このフィールドの詳細についてはセクション7を参照してください。アドレスを含むリンクレイヤレン長オクテットフィールド。
extra-addresses Specifies the number of additional addresses that follow the address specified in link-layer-address. For a single address, 0 is used. For example, link-layer-address 02:04:06:08:0a and extra-addresses 3 designate a block of four addresses, starting from 02:04:06:08:0a and ending with 02:04:06:08:0d (inclusive). A 4-octet field containing an unsigned integer.
extra-addresse link-layer-addressで指定されたアドレスに続く追加アドレスの数を指定します。単一のアドレスの場合、0が使用されます。たとえば、Link-Layer-Address 02：04：06：08：0aとExtrable-Jodees 3 02：04：06：08：08：08：04：06：08で終了する4つのアドレスのブロックを指定します。：0D（包括的）。符号なし整数を含む4オクテットフィールド。
valid-lifetime The valid lifetime for the address(es) in the option, expressed in units of seconds. A 4-octet field containing an unsigned integer.
有効寿命オプション内のアドレス（ES）の有効な有効期間を秒単位で表します。符号なし整数を含む4オクテットフィールド。
LLaddr-options Any encapsulated options that are specific to this particular address block. Currently, there are no such options defined, but there may be in the future.
lladdr - この特定のアドレスブロックに固有のカプセル化オプションをオプションです。現在、そのようなオプションは定義されていませんが、将来的にあるかもしれません。
In a message sent by a client to a server, the valid lifetime field MUST be set to 0. The server MUST ignore any received value.
クライアントからサーバーに送信されたメッセージでは、有効なLifeTimeフィールドを0に設定しなければなりません (MUST)。サーバーは受信値を無視しなければなりません (MUST)。
In a message sent by a server to a client, the client MUST use the value in the valid lifetime field for the valid lifetime for the address block. The value in the valid lifetime field is the number of seconds remaining in the lifetime.
サーバーからクライアントに送信されたメッセージで、クライアントはアドレスブロックの有効な有効期間の有効なLifeTimeフィールドに値を使用しなければなりません (MUST)。有効なLifeTimeフィールドの値は、有効期間内に残っている秒数です。
As per Section 7.7 of [RFC8415], the valid lifetime of 0xffffffff is taken to mean "infinity" and should be used carefully.
[RFC8415]のセクション7.7によると、0xFFFFFFFFの有効な寿命は「無限大」を意味し、慎重に使用する必要があります。
More than one LLADDR option can appear in an IA_LL option.
IA_LLオプションに複数のLLADDRオプションが表示される可能性があります。
A server selects link-layer addresses to be assigned to an IA_LL according to the assignment policies determined by the server administrator and the requirements of that address space.
サーバは、サーバ管理者によって決定された割り当てポリシーとそのアドレス空間の要件に従って、IA_LLに割り当てられるリンクレイヤアドレスを選択します。
Link-layer addresses are typically specific to a link and the server SHOULD follow the steps in Section 13.1 of [RFC8415] to determine the client's link.
リンク層アドレスは通常、リンクに固有のものであり、サーバーは[RFC8415]のセクション13.1の手順に従ってクライアントのリンクを決定すべきです (SHOULD)。
For IEEE 802 MAC addresses (see [IEEEStd802] as amended by [IEEEStd802c]):
IEEE 802 MACアドレスの場合（[IEEESTD802C]で修正された[IEEESTD802]を参照）。
1. Server administrators SHOULD follow the IEEE 802 Specifications with regard to the unicast address pools made available for assignment (see Appendix A and [IEEEStd802c]) -- only address space reserved for local use or with the authorization of the assignee may be used.
1. サーバー管理者は、割り当てに利用可能にするユニキャストアドレスプールに関して、IEEE 802の仕様（付録Aと[IEEEStd802c]を参照）に従うべきです (SHOULD)。つまり、ローカル用途に予約されたアドレス空間、または割り当て先の許可を得たアドレス空間のみを使用できます。
2. Servers MUST NOT allow administrators to configure address pools that would cross the boundary of 2^(42) bits (for 48-bit MAC addresses) to avoid issues with changes in the first octet of the address and the special bits therein (see Appendix A). Clients MUST reject assignments where the assigned block would cross this boundary (they MUST decline the allocation -- see Section 18.2.8 of [RFC8415]).
2. サーバーは、アドレスの最初のオクテットとその中の特別なビットの変化に関する問題を回避するために、管理者が2 ^（42）ビットの境界（48ビットMACアドレスの場合）の境界を渡るアドレスプールを設定できるようにしてはいけません（付録Aを参照）。）。クライアントは、割り当てられたブロックがこの境界を渡ると割り当てを拒否する割り当てを拒否しなければなりません（[RFC8415]の[節約]セクション18.2.8を参照）。
3. A server MAY use options supplied by a relay agent or client to select the quadrant (see Appendix A) from which addresses are to be assigned. This MAY include options like those specified in [RFC8948].
3. サーバーは、中継エージェントまたはクライアントによって提供されたオプションを使用して、アドレスを割り当てるべき象限を選択します（付録Aを参照）。これには、[RFC8948]で指定されたもののようなオプションが含まれる場合があります。
IANA has assigned the OPTION_IA_LL (138) option code from the "Option Codes" subregistry of the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry maintained at <http://www.iana.org/assignments/dhcpv6-parameters>:
IANAは、<http://www.iana.org/assignments/dhcpv6-parameters>に保持されている「動的ホスト構成プロトコル（DHCPv6）」レジストリの「オプションコード」のサブレジストリからOption_ia_LL（138）オプションコードを割り当てました。：
Value: 138 Description: OPTION_IA_LL Client ORO: No Singleton Option: No Reference: RFC 8947
値：138説明：OPTION_IA_LLクライアントORO：いいえシングルトンオプション：参照なし：RFC 8947
IANA has assigned the OPTION_LLADDR (139) option code from the "Option Codes" subregistry of the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry maintained at <http://www.iana.org/assignments/dhcpv6-parameters>:
IANAは、<http://www.iana.org/assignments/dhcpv6-parameters>に維持されている「動的ホスト構成プロトコル（DHCPv6）」レジストリの「オプションコード」サブリズムからoption_lladdr（139）オプションコードを割り当てました。：
Value: 139 Description: OPTION_LLADDR Client ORO: No Singleton Option: No Reference: RFC 8947
値：139説明：OPTION_LLADDRクライアントORO：いいえシングルトンオプション：参照なし：RFC 8947
| DHCP lacks end-to-end encryption between clients and servers; thus, hijacking, tampering, and eavesdropping attacks are all possible as a result.
| DHCPにはクライアントとサーバー間のエンドツーエンド暗号化がありません。そのため、ハイジャック、改ざん、盗聴の攻撃がすべて発生する可能性があります。
In some network environments, it is possible to secure them, as discussed later in Section 22 of [RFC8415].
いくつかのネットワーク環境では、[RFC8415]のセクション22で後述するように、それらを固定することが可能です。
If not all parties on a link use this mechanism to obtain an address from the space assigned to the DHCP server, there is the possibility of the same link-layer address being used by more than one device. Note that this issue would exist on these networks even if DHCP were not used to obtain the address.
リンク上のすべての当事者がこのメカニズムを使用してDHCPサーバーに割り当てられているスペースからアドレスを取得する場合は、同じリンク層アドレスが複数のデバイスで使用される可能性があります。DHCPがアドレスを取得するために使用されなくても、この問題はこれらのネットワーク上に存在することに注意してください。
Server implementations SHOULD consider configuration options to limit the maximum number of addresses to allocate (both in a single request and in total) to a client. However, note that this does not prevent a bad client actor from pretending to be many different clients and consuming all available addresses.
サーバー実装では、（単一の要求と合計で）割り当てる最大アドレス数をクライアントに制限するための設定オプションを検討すべきです (SHOULD)。ただし、これにより、不良クライアントアクターが多くの異なるクライアントになり、利用可能なすべてのアドレスを消費することを妨げないことに注意してください。
See Section 23 of [RFC8415] for the DHCP privacy considerations.
DHCPプライバシーに関する考慮事項については、[RFC8415]のセクション23を参照してください。
For a client requesting a link-layer address directly from a server, as the address assigned to a client will likely be used by the client to communicate on the link, the address will be exposed to those able to listen in on this communication. For those peers on the link that are able to listen in on the DHCP exchange, they would also be able to correlate the client's identity (based on the DUID used) with the assigned address. Additional mechanisms, such as the ones described in [RFC7844], can also be used to improve anonymity by minimizing what is exposed.
クライアントから直接リンク層アドレスを要求するために、クライアントに割り当てられたアドレスがリンク上で通信するためにクライアントによって使用される可能性が高いため、この通信で待機できるようにアドレスが公開されます。DHCP Exchangeで待機できるリンクのピアの場合、それらは、クライアントの識別情報（使用されているDUIDに基づく）を割り当てられたアドレスと相関させることができるでしょう。[RFC7844]に記載されているものなどの追加のメカニズムを使用して、露光されているものを最小限に抑えることで匿名性を向上させることもできます。
As discussed in Section 23 of [RFC8415], DHCP servers and hypervisors may need to consider the implications of assigning addresses sequentially. Though in general, this is only of link-local concern unlike for IPv6 address assignment and prefix delegation, as these may be used for communication over the Internet.
[RFC8415]のセクション23で説明したように、DHCPサーバーとハイパーバイザーは、アドレスを順番に割り当てることの影響を考慮する必要があるかもしれません。一般に、これはIPv6アドレス割り当てと接頭辞委任とは異なり、インターネットを介した通信に使用できるように、リンクローカルの関心事のみです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner, S.、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/rfc2119>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman、「IPバージョン6（IPv6）の隣接発見（IPv6）」、RFC 4861、DOI 10.17487/RFC4861、2007年9月、<https://www.rfc-editor.org/info/rfc4861>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba, B.、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https://www.rfc-editor.org/info/rfc8174>。
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.
[IEEE-P802.1CQ-Project] IEEE, "P802.1CQ - Standard for Local and Metropolitan Area Networks: Multicast and Local Address Assignment", <https://standards.ieee.org/project/802_1CQ.html>.
[IEEE-P802.1CQ-Project] IEEE、「P802.1CQ - ローカルおよびメトロポリタンエリアネットワークの規格：マルチキャストとローカルアドレス割り当て」、<https://standards.ieee.org/project/802_1CQ.html>。
[IEEEStd802] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture, IEEE Std 802", IEEE STD 802-2014, DOI 10.1109/IEEESTD.2014.6847097, <https://doi.org/10.1109/IEEESTD.2014.6847097>.
[IEEEStd802] IEEE、「地方および首都圏ネットワークのIEEE規格：概要と建築、IEEE STD 802」、IEEE STD 802-2014、DOI 10.1109/IEEESTD.2014.6847097、<https://doi.org/10.1109/IEEESTD.2014.6847097>。
[IEEEStd802.11] IEEE, "IEEE Standard for Information technology-- Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std 802.11, DOI 10.1109/IEEESTD.2016.7786995, <https://doi.org/10.1109/IEEESTD.2016.7786995>.
[IEEEStd802.11] IEEE、「IEEE規格情報技術標準 - システム間の電気通信と情報交換」ネットワーク - 特定の要件 - 第11部：無線LANメディアアクセス制御（MAC）および物理層（PHY）仕様）、IEEE STD 802.11、DOI 10.1109/IEEESTD.2016.7786995、<https://doi.org/10.1109/IEEESTD.2016.7786995>。
[IEEEStd802c] IEEE, "IEEE Standard for Local and Metropolitan Area Networks:Overview and Architecture--Amendment 2: Local Medium Access Control (MAC) Address Usage", IEEE Std 802c-2017, DOI 10.1109/IEEESTD.2017.8016709, <https://doi.org/10.1109/IEEESTD.2017.8016709>.
[IEEEStd802c] IEEE、「ローカル・メトロポリタン・エリア・ネットワークのIEEE規格：概要とアーキテクチャー・アンド・アンド・アーデーション2：地元の中アクセス制御（Mac）アドレス使用量」、IEEE STD 802C-2017、DOI 10.1109/IEEESTD.2017.8016709、<https://doi.org/10.1109/IEEESTD.2017.8016709>。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, <https://www.rfc-editor.org/info/rfc2464>.
[RFC2464] Crawford, M.、「イーサネットネットワークを介したIPv6パケットの送信」、RFC 2464、DOI 10.17487/RFC2464、1998年12月、<https://www.rfc-editor.org/info/rfc2464>。
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, <https://www.rfc-editor.org/info/rfc4429>.
[RFC4429] Moore, N.、「IPv6のための楽観的な重複アドレス検出（DAD）」、RFC 4429、DOI 10.17487/RFC4429、2006年4月、<https://www.rfc-editor.org/info/rfc4429>。
[RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines for the Address Resolution Protocol (ARP)", RFC 5494, DOI 10.17487/RFC5494, April 2009, <https://www.rfc-editor.org/info/rfc5494>.
[RFC5494] Arkko、J.およびC. Pignataro、2009年4月、<https://www.rfc-editor.org/info/rfc5494>。
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, <https://www.rfc-editor.org/info/rfc7227>.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan、「新しいDHCPv6のオプションを作成するためのガイドライン」、BCP 187、RFC 7227、DOI 10.17487/RFC7227、2014年5月<https://www.rfc-editor.org/info/rfc7227>。
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen、「拘束ノードネットワークのための用語」、RFC 7228、DOI 10.17487 / RFC 7228、2014年5月、<https://www.rfc-editor.org/info/rfc7228>。
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, <https://www.rfc-editor.org/info/rfc7844>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan、「DHCPクライアントの匿名性プロファイル」、RFC 7844、DOI 10.17487/RFC7844、2016年5月、<https://www.rfc-editor.org/info/rfc7844>。
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200] Deering, S. and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487/RFC8200、2017年7月、<https://www.rfc-editor.org/info/rfc8200>。
[RFC8948] Bernardos, CJ. and A. Mourad, "Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6", RFC 8948, DOI 10.17487/RFC8948, December 2020, <https://www.rfc-editor.org/info/rfc8948>.
[RFC8948] Bernardos、CJ。A. Mourad、DHCPv6の「構造化されたローカルアドレスプラン（Slap）象限選択オプション」、RFC 8948、DOI 10.17487/RFC8948、2020年12月、<https://www.rfc-editor.org/info/rfc8948>。
This appendix provides a brief summary of IEEE 802c [IEEEStd802c].
この付録では、IEEE 802C [IEEESTD802C]の簡単な概要を説明します。
The original IEEE 802 specifications assigned half of the 48-bit MAC address space to local use -- these addresses have the U/L bit set to 1 and are locally administered with no imposed structure.
オリジナルのIEEE 802仕様は、ローカル使用に48ビットMACアドレス空間の半分を割り当てた - これらのアドレスには、U/Lビットが1に設定され、局所的に施されていない構造で管理されています。
In 2017, the IEEE issued the IEEE Std 802c specification, which defines a new optional "Structured Local Address Plan (SLAP) that specifies different assignment approaches in four specified regions of the local MAC address space". Under this plan, there are four SLAP quadrants that use different assignment policies.
2017年には、IEEEはIEEE STD 802C仕様を発行しました。これは、ローカルMACアドレス空間の4つの指定された領域で異なる割り当てアプローチを指定する新しいオプションの「構造化ローカルアドレスプラン（SLAP）」を定義しました。この計画では、異なる割り当てポリシーを使用する4つのスラップ象限があります。
The first octet of the MAC address Z and Y bits define the quadrant for locally assigned addresses (X-bit is 1). In IEEE representation, these bits are as follows:
MACアドレスZおよびYビットの最初のオクテットは、局所割り当てアドレスの象限を定義する（Xビットは1）。IEEE表現では、これらのビットは次のとおりです。
LSB MSB
M X Y Z - - - -
| | | |
| | | +------------ SLAP Z-bit
| | +--------------- SLAP Y-bit
| +------------------ X-bit (U/L) = 1 for locally assigned
+--------------------- M-bit (I/G) (unicast/group)
Figure 3: SLAP Bits
図3：スラップビット
The SLAP quadrants are:
スラップ象限は次のとおりです。
+==========+=======+=======+=======================+============+
| Quadrant | Y-bit | Z-bit | Local Identifier Type | Local |
| | | | | Identifier |
+==========+=======+=======+=======================+============+
| 01 | 0 | 1 | Extended Local | ELI |
+----------+-------+-------+-----------------------+------------+
| 11 | 1 | 1 | Standard Assigned | SAI |
+----------+-------+-------+-----------------------+------------+
| 00 | 0 | 0 | Administratively | AAI |
| | | | Assigned | |
+----------+-------+-------+-----------------------+------------+
| 10 | 1 | 0 | Reserved | Reserved |
+----------+-------+-------+-----------------------+------------+
Table 1: SLAP Quadrants
表1：スラップ象限
MAC addresses derived from an Extended Local Identifier (ELI) are based on an assigned Company ID (CID), which is 24 bits (including the M, X, Y, and Z bits) for 48-bit MAC addresses. This leaves 24 bits for the locally assigned address for each CID for unicast (M-bit = 0) and also for multicast (M-bit = 1). The CID is assigned by the IEEE Registration Authority (RA).
拡張ローカル識別子（ELI）から派生したMACアドレスは、48ビットMACアドレスに対して24ビット（M、X、Y、およびZビットを含む）である割り当てられた会社ID（CID）に基づいています。これにより、ユニキャスト用の各CID（Mビット= 0）ごとに、およびマルチキャスト（Mビット= 1）の場合も、ローカルに割り当てられたアドレスの24ビットが残ります。CIDはIEEE登録局（RA）によって割り当てられています。
MAC addresses derived from a Standard Assigned Identifier (SAI) are assigned by a protocol specified in an IEEE 802 standard. For 48-bit MAC addresses, 44 bits are available. Multiple protocols for assigning SAIs may be specified in IEEE standards. Coexistence of multiple protocols may be supported by limiting the subspace available for assignment by each protocol.
標準割り当て識別子（SAI）から派生したMACアドレスは、IEEE 802規格で指定されたプロトコルによって割り当てられています。48ビットMACアドレスの場合、44ビットがあります。SAISを割り当てるための複数のプロトコルは、IEEE規格で指定できます。複数のプロトコルの共存は、各プロトコルによる割り当てに利用可能なサブスペースを制限することによってサポートされてもよい。
MAC addresses derived from an Administratively Assigned Identifier (AAI) are assigned locally. Administrators manage the space as needed. Note that multicast IPv6 packets [RFC2464] use a destination address starting in 33-33, so AAI addresses in that range should not be assigned. For 48-bit MAC addresses, 44 bits are available.
管理上割り当てられた識別子（AAI）から派生したMACアドレスはローカルに割り当てられています。管理者は必要に応じてスペースを管理します。マルチキャストIPv6パケット[RFC2464]は33-33で開始先アドレスを使用するため、その範囲内のAAIアドレスを割り当てないでください。48ビットMACアドレスの場合、44ビットがあります。
The last quadrant is reserved for future use. While this quadrant may also be used similar to AAI space, administrators should be aware that future specifications may define alternate uses that could be incompatible.
最後の象限は将来の使用のために予約されています。この象限はAAIスペースと同様に使用されている可能性があるが、管理者は将来の仕様が互換性がない代替用途を定義できることに注意する必要があります。
Acknowledgments
謝辞
Thanks to the DHC Working Group participants that reviewed this document and provided comments and support. With special thanks to Ian Farrer for his thorough reviews and shepherding of this document through the IETF process. Thanks also to directorate reviewers Samita Chakrabarti, Roni Even, and Tianran Zhou and IESG members Martin Duke, Benjamin Kaduk, Murray Kucherawy, Warren Kumari, Barry Leiba, Alvaro Retana, Éric Vyncke, and Robert Wilton for their suggestions. And thanks to Roger Marks, Robert Grow, and Antonio de la Oliva for comments related to IEEE work and references.
この文書をレビューし、コメントとサポートを提供したDHCワーキンググループ参加者のおかげで。IETFプロセスを通じてこの文書の徹底的なレビューとシェパードのためのIan Farrerに感謝します。Distrance Reviewers Samita Chakrabarti、Roniさえ、Tianran ZhouとIesgメンバーMartin Duke、Benjamin Kaduk、Murray Kucherawy、Warren Kumari、Barry Leiba、Alvaro Retana、ÉricVyncke、Robert Wilton、およびRobert Wilton。そして、Roger Marks、Robert Grow、およびAntonio de la Olivaのおかげで、IEEEの仕事や参照に関連するコメントについて。
Authors' Addresses
著者の住所
Bernie Volz Cisco Systems, Inc. 300 Beaver Brook Rd Boxborough, MA 01719 United States of America
Bernie Volz Cisco Systems、Inc。300ビーバーブルックRD Boxborough、MA 01719アメリカ合衆国
Email: volz@cisco.com
Tomek Mrugalski Internet Systems Consortium, Inc. PO Box 360 Newmarket, NH 03857 United States of America
Tomek Mrugalskiインターネットシステムコンソーシアム、Inc。PO BOX 360 Newmarket、NH 03857アメリカ合衆国
Email: tomasz.mrugalski@gmail.com
Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 28911 Leganes, Madrid Spain
Carlos J. Bernardos Universidad Carlos Iii de Madrid AV。Envideridad、30 28911 Leganes、マドリードスペイン
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/