[要約] RFC 8948は、DHCPv6におけるStructured Local Address Plan (SLAP) Quadrant Selection Optionを定義しています。この文書の目的は、ローカルネットワーク内でIPv6アドレスの割り当てをより柔軟に管理するための方法を提供することです。利用場面としては、大規模な組織やISPがネットワーク内でのアドレス管理を効率化し、運用を簡素化する場合に適しています。
Internet Engineering Task Force (IETF) CJ. Bernardos
Request for Comments: 8948 UC3M
Category: Standards Track A. Mourad
ISSN: 2070-1721 InterDigital
December 2020
Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6
DHCPv6の構造化されたローカルアドレスプラン（SLAP）象限選択オプション
Abstract
概要
The IEEE originally structured the 48-bit Media Access Control (MAC) address space in such a way that half of it was reserved for local use. In 2017, the IEEE published a new standard (IEEE Std 802c) with a new optional Structured Local Address Plan (SLAP). It specifies different assignment approaches in four specified regions of the local MAC address space.
IEEEは、第48ビットメディアアクセス制御（MAC）アドレススペースをローカル使用のために予約されていたように、48ビットメディアアクセス制御（MAC）アドレス空間を構成しました。2017年、IEEEは新しい標準（IEEE STD 802C）を公開しました（IEEE STD 802C）、新しいオプションの構造化ローカルアドレスプラン（SLAP）を発行しました。ローカルMACアドレス空間の4つの指定された領域で異なる割り当てアプローチを指定します。
The IEEE is developing protocols to assign addresses (IEEE P802.1CQ). There is also work in the IETF on specifying a new mechanism that extends DHCPv6 operation to handle the local MAC address assignments.
IEEEはアドレスを割り当てるためのプロトコルを開発しています（IEEE P802.1CQ）。また、Local MACアドレス割り当てを処理するためにDHCPv6操作を拡張する新しいメカニズムを指定する上で、IETFにも機能します。
This document proposes extensions to DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant to the server so that the server may allocate MAC addresses in the quadrant requested by the relay or client. A new DHCPv6 option (QUAD) is defined for this purpose.
この文書は、DHCPv6プロトコルまたはDHCPv6リレーを使用して、サーバーがリレーまたはクライアントによって要求された象限でMACアドレスを割り当てることができるように、DHCPv6クライアントまたはDHCPv6リレーをサーバーに表示できるようにするためにDHCPv6プロトコルを提案します。この目的のために、新しい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/rfc8948.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8948で入手できます。
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
1.1. Problem Statement
1.1.1. Wi-Fi (IEEE 802.11) Devices
1.1.2. Hypervisor: Functions That Are and Are Not Migratable
2. Terminology
3. DHCPv6 Extensions
3.1. Address Assignment from the Preferred SLAP Quadrant
Indicated by the Client
3.2. Address Assignment from the Preferred SLAP Quadrant
Indicated by the Relay
4. DHCPv6 Option Definition
4.1. QUAD Option
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Example Uses of Quadrant Selection Mechanisms
Acknowledgments
Authors' Addresses
The IEEE structures the 48-bit MAC address space in such a way that half of it is reserved for local use (where the Universal/Local (U/L) bit is set to 1). In 2017, the IEEE published a new standard [IEEEStd802c] that defines a new optional Structured Local Address Plan (SLAP) that specifies different assignment approaches in four specified regions of the local MAC address space. These four regions, called SLAP quadrants, are briefly described below (see Figure 1 and Table 1 for details):
IEEEは、それの半分がローカル使用のために予約されているように48ビットのMACアドレス空間を構成している（Universal / Local（U / L）ビットが1に設定されている場合）。2017年、IEEEは、ローカルMACアドレス空間の4つの指定された領域で異なる割り当てアプローチを指定する新しいオプションの構造化ローカルアドレスプラン（SLAP）を定義する新しい標準[IEEESTD802C]を発表しました。スラップ象限と呼ばれるこれらの4つの領域について、以下に簡単に説明されています（詳細は図1と表1を参照）。
* In SLAP Quadrant 01, Extended Local Identifier (ELI) MAC addresses are assigned based on a 24-bit Company ID (CID), which is assigned by the IEEE Registration Authority (RA). The remaining bits are specified as an extension by the CID assignee or by a protocol designated by the CID assignee.
* スラップ象限01では、拡張ローカル識別子（ELI）MACアドレスが、IEEE登録機関（RA）によって割り当てられている24ビット社のID（CID）に基づいて割り当てられています。残りのビットは、CID担当者による拡張子として、またはCID担当者によって指定されたプロトコルによって指定されます。
* In SLAP Quadrant 11, Standard Assigned Identifier (SAI) MAC addresses are assigned based on 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.
* スラップ象限11では、標準割り当て識別子（SAI）MACアドレスがIEEE802規格で指定されたプロトコルに基づいて割り当てられている。48ビットMACアドレスの場合、44ビットがあります。SAISを割り当てるための複数のプロトコルは、IEEE規格で指定できます。複数のプロトコルの共存は、各プロトコルによる割り当てに利用可能なサブスペースを制限することによってサポートされてもよい。
* In SLAP Quadrant 00, Administratively Assigned Identifier (AAI) MAC addresses are assigned locally by an administrator. Multicast IPv6 packets 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.
* スラップ象限00では、管理上の割り当て識別子（AAI）MACアドレスが管理者によってローカルに割り当てられています。マルチキャストIPv6パケット33-33から開始している宛先アドレスを使用するので、その範囲内のAAIアドレスを割り当てないでください。48ビットMACアドレスの場合、44ビットがあります。
* SLAP Quadrant 10 is "Reserved for future use" where MAC addresses may be assigned using new methods yet to be defined or until then by an administrator as in the AAI quadrant. For 48-bit MAC addresses, 44 bits would be available.
* Slap Quadrant 10は、まだ定義されていない新しいメソッドを使用して、またはAAI象限のように管理者による管理者によってMACアドレスを割り当てることができます。48ビットMACアドレスの場合、44ビットが利用可能になります。
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)
Legend: LSB: Least Significant Bit MSB: Most Significant Bit
LEGEND：LSB：最前有意ビットMSB：最上位ビット
Figure 1: IEEE 48-Bit MAC Address Structure (in IEEE Representation)
図1：IEEE 48ビットMACアドレス構造（IEEE表現）
+==========+=======+=======+=======================+============+
| 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：スラップ象限
The IEEE is developing mechanisms to assign addresses [IEEE-P802.1CQ-Project]. And [RFC8947] specifies a new mechanism that extends DHCPv6 operation to handle the local MAC address assignments. This document proposes extensions to DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant to the server so that the server may allocate the MAC addresses in the quadrant requested by the relay or client.
IEEEは、アドレスを割り当てるメカニズムを開発しています[IEEE-P802.1CQ-PROJECT]。[RFC8947]は、ローカルMACアドレス割り当てを処理するためにDHCPv6操作を拡張する新しいメカニズムを指定します。この文書は、DHCPv6プロトコルまたはDHCPv6リレーを使用可能にして、サーバーがリレーまたはクライアントによって要求された象限でMACアドレスを割り当てることができるように、DHCPv6クライアントまたはDHCPv6リレーをサーバーに表示できるようにします。
In the following, we describe two application scenarios in which a need arises to assign local MAC addresses according to preferred SLAP quadrants.
以下では、優先スラップ象限に従ってローカルMACアドレスを割り当てる必要があるという2つのアプリケーションシナリオについて説明します。
Today, most Wi-Fi devices come with interfaces that have a "burned-in" MAC address, allocated from the universal address space using a 24-bit Organizationally Unique Identifier (OUI) (assigned to IEEE 802 interface vendors). However, recently, the need to assign local (instead of universal) MAC addresses has emerged particularly in the following two scenarios:
今日、ほとんどのWi-Fiデバイスには、24ビットの組織的に一意の識別子（OUI）を使用してユニバーサルアドレス空間から割り当てられたインターフェイスが付属しています（IEEE 802インターフェイスベンダーに割り当てられます）。ただし、最近、（Universalの代わりに）ローカルを割り当てる必要があります.MACアドレスは、特に次の2つのシナリオで発生しました。
* IoT (Internet of Things): In general, composed of constrained devices [RFC7228] with constraints such as available power and energy, memory, and processing resources. Examples of this include sensors and actuators for health or home automation applications. Given the increasingly high number of these devices, manufacturers might prefer to equip devices with temporary MAC addresses used only at first boot. These temporary MAC addresses would just be used to send initial DHCP packets to available DHCP servers. IoT devices typically need a single MAC address for each available network interface. Once the server assigns a MAC address, the device would abandon its temporary MAC address. Home automation IoT devices typically do not move (however, note that there is an increase of mobile smart health monitoring devices). For this type of device, in general, any type of SLAP quadrant would be good for assigning addresses, but ELI/SAI quadrants might be more suitable in some scenarios. For example, the device might need to use an address from the CID assigned to the IoT communication device vendor, thus preferring the ELI quadrant.
* IOT（インターネットのインターネット）：一般的に、利用可能な電力とエネルギー、メモリ、および処理リソースなどの制約を伴う制約付きデバイス[RFC7228]で構成されています。この例としては、ヘルスまたはホームオートメーションアプリケーション用のセンサーおよびアクチュエータが含まれる。これらのデバイスがますます多数のデバイスを考えると、メーカーは最初の起動時にのみ使用されている一時的なMACアドレスを持つデバイスを装備することを好むことがあります。これらの一時的なMACアドレスは、初期DHCPパケットを利用可能なDHCPサーバーに送信するために使用されます。 IOTデバイスは通常、利用可能な各ネットワークインターフェイスに対して単一のMACアドレスが必要です。サーバーがMACアドレスを割り当てると、デバイスは一時的なMACアドレスを放棄します。ホームオートメーションIOTデバイスは通常移動しない（ただし、モバイルスマートヘルスモニタリングデバイスの増加があることに注意してください）。このタイプのデバイスの場合、一般に、どのような種類のスラップ象限はアドレスの割り当てに適していますが、ELI / SAI象限はいくつかのシナリオでもっと適している可能性があります。たとえば、デバイスは、IOT通信デバイスベンダーに割り当てられているCIDからアドレスを使用する必要があり、したがってELI象限を好むことができます。
* Privacy: Today, MAC addresses allow the exposure of user locations making it relatively easy to track user movements. One of the mechanisms considered to mitigate this problem is the use of local random MAC addresses: changing them every time the user connects to a different network. In this scenario, devices are typically mobile. Here, AAI is probably the best SLAP quadrant from which to assign addresses; it is the best fit for randomization of addresses, and it is not required for the addresses to survive when changing networks.
* プライバシー：今日、MACアドレスでは、ユーザーの移動を比較的簡単に追跡するユーザーの場所のエクスポージャーが許可されています。この問題を軽減すると考えられるメカニズムの1つは、ローカルのランダムMACアドレスの使用です。ユーザーが別のネットワークに接続するたびにそれらを変更することです。このシナリオでは、デバイスは通常モバイルです。ここで、AAIはおそらくアドレスを割り当てるための最高のスラップ象限です。それは住所のランダム化に最適であり、ネットワークを変更するときに住所が生き残るために必要ではありません。
In large-scale virtualization environments, thousands of virtual machines (VMs) are active. These VMs are typically managed by a hypervisor, which is in charge of spawning and stopping VMs as needed. The hypervisor is also typically in charge of assigning new MAC addresses to the VMs. If a DHCP solution is in place for that, the hypervisor acts as a DHCP client and requests that available DHCP servers assign one or more MAC addresses (an address block). The hypervisor does not use those addresses for itself, but rather it uses them to create new VMs with appropriate MAC addresses. If we assume very large data-center environments, such as the ones that are typically used nowadays, it is expected that the data center is divided in different network regions, each one managing its own local address space. In this scenario, there are two possible situations that need to be tackled:
大規模仮想化環境では、何千もの仮想マシン（VM）がアクティブです。これらのVMは通常ハイパーバイザーによって管理されています。これは、必要に応じて登録とVMSの停止を担当しています。ハイパーバイザーは通常、新しいMACアドレスをVMに割り当てることも担当しています。そのためにDHCPソリューションが整っている場合、ハイパーバイザーはDHCPクライアントとして機能し、使用可能なDHCPサーバーが1つ以上のMACアドレス（アドレスブロック）を割り当てるよう要求します。ハイパーバイザーはそれ自体にそれらのアドレスを使用しませんが、それらを使用して適切なMACアドレスを持つ新しいVMを作成します。今日で通常使用されているものなどの非常に大きなデータセンター環境を仮定すると、データセンターが異なるネットワーク地域に分割され、それぞれが独自のローカルアドレス空間を管理することが予想されます。このシナリオでは、取り組む必要がある2つの可能な状況があります。
* Migratable functions: If a VM (providing a given function) needs to be migrated to another region of the data center (e.g., for maintenance, resilience, end-user mobility, etc.), the VM's networking context needs to migrate with the VM. This includes the VM's MAC address(es). Since the assignments from the ELI/SAI SLAP quadrants are governed by rules per IEEE Std 802c, they are more appropriate for use to ensure MAC address uniqueness globally in the data center.
* 移行可能な機能：VM（与えられた関数を提供する）をデータセンターの別の領域（例えば、メンテナンス、回復力、エンドユーザーモビリティなど）に移行する必要がある場合、VMのネットワークコンテキストはVMと移行する必要があります。。これには、VMのMACアドレスが含まれます。ELI / SAIスラップ象限からの割り当てはIEEE STD 802Cごとに規則によって支配されているため、データセンターでMACアドレスの一意性を確保するために使用に適しています。
* Functions that are not migratable: If a VM will not be migrated to another region of the data center, there are no requirements associated with its MAC address. In this case, it is simpler to allocate it from the AAI SLAP quadrant, which does not need to be unique across multiple data centers (i.e., each region can manage its own MAC address assignment without checking for duplicates globally).
* 移行可能な機能：VMがデータセンターの別の領域に移行されない場合、そのMACアドレスに関連付けられている要件はありません。この場合、AIスラップ象限からそれを割り当てることがより簡単であり、これは複数のデータセンターに一意である必要はない（すなわち、各領域は、グローバルに重複をチェックすることなくそれ自身のMACアドレス割り当てを管理することができる）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Where relevant, the DHCPv6 terminology from [RFC8415] also applies here. Additionally, the following definitions are updated for this document.
関連する場合、[RFC8415]からのDHCPv6の用語もここに適用されます。さらに、この文書に対して次の定義が更新されます。
address Unless specified otherwise, a link-layer (or MAC) address, as specified in [IEEEStd802]. The address is 6 or 8 bytes long.
特記しない限り、[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 options (IA_LL and LLADDR) specified in [RFC8947] as well as the new option (QUAD) specified in this document. The client may or may not support IPv6 address assignment and prefix delegation, as specified in [RFC8415].
クライアントリンクレイヤアドレスを取得することに関心があるノード。[RFC8415]で説明されているように、DHCPクライアントが必要とする基本的なDHCPメカニズムを実装し、[RFC8947]で指定されたオプション（IA_LLとLLADDR）とこのドキュメントで指定された新しいオプション（クワッド）をサポートします。[RFC8415]で指定されているように、クライアントはIPv6アドレス割り当てとプレフィックスの委任をサポートしていない可能性があります。
IA_LL Identity Association for Link-Layer Address, an identity association (IA) used to request or assign link-layer addresses. Section 11.1 of [RFC8947] provides details on the IA_LL option.
リンク層アドレス、リンク層アドレスを要求または割り当てるために使用されるIDLEDアドレスのIA_LL ID関連付け。[RFC8947]のセクション11.1は、IA_LLオプションの詳細を示しています。
LLADDR Link-layer address option that is used to request or assign a block of link-layer addresses. Section 11.2 of [RFC8947] provides details on the LLADDR option.
LLADDRリンク層アドレスを要求または割り当てるために使用されるオプション。[RFC8947]のセクション11.2はLLADDRオプションの詳細を示しています。
relay A node that acts as an intermediary to deliver DHCP messages between clients and servers. A relay, based on local knowledge and policies, may include the preferred SLAP quadrant in a QUAD option sent to the server. The relay implements basic DHCPv6 relay agent functionality, as described in [RFC8415].
リレー仲介者として機能するノードをクライアントとサーバー間でDHCPメッセージを配信します。ローカルの知識とポリシーに基づくリレーは、サーバーに送信されたクワッドオプションで優先スラップ象限を含めることができます。[RFC8415]で説明されているように、リレーは基本的なDHCPv6リレーエージェント機能を実装しています。
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 options (IA_LL and LLADDR) specified in [RFC8947] as well as the new option (QUAD) specified in this document. The server may or may not support IPv6 address assignment and prefix delegation, as specified in [RFC8415].
サーバーリンクレイヤアドレス割り当てを管理するノードとクライアントクエリに応答できるノード。[RFC8415]で説明されているように、基本的なDHCPサーバー機能を実装し、[RFC8947]で指定されたオプション（IA_LLとLLADDR）とこのドキュメントで指定された新しいオプション（クワッド）をサポートします。[RFC8415]で指定されているように、サーバーはIPv6アドレス割り当てとプレフィックスの委任をサポートしている場合があります。
3.1. Address Assignment from the Preferred SLAP Quadrant Indicated by the Client
3.1. クライアントが示す優先スラップ象限からのアドレス割り当て
Next, we describe the protocol operations for a client to select a preferred SLAP quadrant using the DHCPv6 signaling procedures described in [RFC8947]. The signaling flow is shown in Figure 2.
次に、[RFC8947]に記載されているDHCPv6シグナリング手順を使用して、クライアントのプロトコル操作を説明する。シグナリングフローを図2に示す。
+--------+ +--------+
| DHCPv6 | | DHCPv6 |
| client | | server |
+--------+ +--------+
| |
+----1. Solicit(IA_LL(LLADDR,QUAD))--->|
| |
|<--2. Advertise(IA_LL(LLADDR,QUAD))---+
| |
+---3. Request(IA_LL(LLADDR,QUAD))---->|
| |
|<------4. Reply(IA_LL(LLADDR))--------+
| |
. .
. (timer expiring) .
. .
| |
+---5. Renew(IA_LL(LLADDR,QUAD))------>|
| |
|<-----6. Reply(IA_LL(LLADDR))---------+
| |
Figure 2: DHCPv6 Signaling Flow (Client-Server)
図2：DHCPv6シグナリングフロー（クライアントサーバー）
1. Link-layer addresses (i.e., MAC 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 in the message. The IA_LL option MUST contain an LLADDR option. In order to indicate the preferred SLAP quadrant(s), the IA_LL option includes the new OPTION_SLAP_QUAD option in the IA_LL-option field (alongside the LLADDR option).
1. リンク層アドレス（すなわち、MACアドレス）がブロック内で割り当てられる。最小ブロックは単一のアドレスです。割り当てを要求するために、クライアントはメッセージ内のIA_LLオプションを含む募話メッセージを送信します。IA_LLオプションにはLLADDRオプションが含まれている必要があります。優先スラップ象限を示すために、IA_LLオプションはIA_LL - オプションフィールドに新しいOption_SLAP_QUADオプションを含みます（LLADDRオプションと一緒に）。
2. The server, upon receiving an IA_LL option in a Solicit message, inspects its contents. For each of the entries in the OPTION_SLAP_QUAD, in order of the preference field (highest to lowest), the server checks if it has a configured MAC address pool matching the requested quadrant identifier and an available range of addresses of the requested size. If suitable addresses are found, 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 manages a block of addresses belonging to a requested quadrant, the addresses being offered MUST belong to a requested quadrant. If the server does not have a configured address pool matching the client's request, it SHOULD return the IA_LL option with the addresses being offered belonging to a quadrant managed by the server (following a local policy to select from which of the available quadrants). If the server has a configured address pool of the correct quadrant but no available addresses, it MUST return the IA_LL option containing a Status Code option with status set to NoAddrsAvail.
2. サーバーは、勧誘メッセージでIA_LLオプションを受信したときに、その内容を検査します。 Option_SLAP_QUADの各エントリについて、Preferenceフィールド（最低から最小値）の順に、サーバーは、要求された象限識別子と要求されたサイズの利用可能なアドレスの使用可能な範囲の設定済みのMACアドレスプールがあるかどうかを確認します。適切なアドレスが見つかった場合、サーバーは、提供されているアドレスを指定するLLADDRオプションを含むIA_LLオプションを含むアドバタイズメッセージを送り返します。サーバーが要求された象限に属するアドレスのブロックを管理する場合、提供されているアドレスは要求された象限に属している必要があります。サーバーにクライアントの要求と一致する設定済みのアドレスプールがない場合は、サーバーによって管理されている象限に属するアドレスが提供されているアドレスを返します（ローカルポリシーから、利用可能な象限のどちらから選択します）。サーバーに正しい象限の設定されたアドレスプールがあるが、利用可能なアドレスがない場合は、Status Codeオプションを含むIA_LLオプションをNoAddrSavailに設定する必要があります。
3. 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 SHOULD NOT pick a server that does not advertise an address in the requested quadrant(s). 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. It includes the preferred SLAP quadrant(s) in a new QUAD IA_LL option.
3. クライアントは、[RFC8415]のセクション18.2.9で定義されているように、Advertise Responsesを送信し、1つのサーバーを選択するのを待ちます。クライアントは、要求された象限内のアドレスをアドバタイズしないサーバーを選択しないでください。その後、クライアントは、選択されたサーバーによって送信されたアドバタイズメッセージからコピーされたLLADDRオプションを含むIA_LLコンテナオプションを含む要求メッセージを送信します。新しいクワッドIA_LLオプションには、優先スラップ象限が含まれています。
4. Upon reception of a Request message with an IA_LL container option, the server assigns requested addresses. The server MAY alter the allocation at this time (e.g., by reducing the address block). It then generates and sends a Reply message back to the client. Upon receiving a Reply message, the client parses the IA_LL container option and may start using all provided addresses. Note that a client that has included a Rapid Commit option in the Solicit message may receive a Reply message in response to the Solicit message and skip the Advertise and Request message steps above (following standard DHCPv6 procedures).
4. IA_LLコンテナオプションを使用して要求メッセージを受信すると、サーバーは要求されたアドレスを割り当てます。サーバは、このときの割り当てを（例えば、アドレスブロックを減らすことによって）割り当てを変更することができる。その後、返信メッセージをクライアントに返送して送信します。返信メッセージを受信すると、クライアントはIA_LLコンテナオプションを解析し、提供されているすべてのアドレスを使用して開始されます。閲覧メッセージにRapid Commitオプションを含めたクライアントは、閲覧メッセージに応答して返信メッセージを受信し、上記のアドバタイズおよび要求の手順をスキップすることができる（標準のDHCPv6手順の後）。
5. The client is expected to periodically renew the link-layer addresses, as governed by T1 and T2 timers. This mechanism can be administratively disabled by the server sending "infinity" as the T1 and T2 values (see Section 7.7 of [RFC8415]). The client sends a Renew option after T1. It includes the preferred SLAP quadrant(s) in the new QUAD IA_LL option, so in case the server is unable to extend the lifetime on the existing address(es), the preferred quadrants are known for the allocation of any "new" (i.e., different) addresses.
5. T1およびT2のタイマによって管理されているように、クライアントはリンク層アドレスを定期的に更新することが期待されています。このメカニズムは、T1とT2の値として「Infinity」を送信するサーバーによって管理上無効にすることができます（[RFC8415]のセクション7.7を参照）。クライアントはT1の後に更新オプションを送信します。それは新しいクワッドia_llオプションで優先スラップ象限を含むので、サーバが既存のアドレス（ES）上の寿命を拡張することができない場合、好ましい象限は任意の「新規」の割り当てについて知られている（すなわち、異なる）アドレス。
6. The server responds with a Reply message with an IA_LL option that includes an LLADDR option with extended lifetime.
6. サーバーは、拡張された有効期間のLLADDRオプションを含むIA_LLオプションを含む応答メッセージで応答します。
The client SHOULD check if the received MAC address comes from one of the requested quadrants. It MAY repeat the process selecting a different DHCP server.
クライアントは、受信したMACアドレスが要求された象限の1つから来るかどうかを確認する必要があります。それは異なるDHCPサーバーを選択するプロセスを繰り返すかもしれません。
3.2. Address Assignment from the Preferred SLAP Quadrant Indicated by the Relay
3.2. リレーが示す優先スラップ象限からのアドレス割り当て
Next, we describe the protocol operations for a relay to select a preferred SLAP quadrant using the DHCPv6 signaling procedures described in [RFC8947]. This is useful when a DHCPv6 server is operating over a large infrastructure split in different network regions, where each region might have different requirements. The signaling flow is shown in Figure 3.
次に、[RFC8947]に記載されているDHCPV6シグナリング手順を使用して、優先スラップ象限を選択するためのプロトコル操作について説明します。これは、DHCPv6サーバーがさまざまなネットワーク地域で分割された大規模インフラストラクチャを介して動作している場合、各地域には異なる要件がある場合があります。シグナリングフローを図3に示す。
+--------+ +--------+ +--------+
| DHCPv6 | | DHCPv6 | | DHCPv6 |
| client | | relay | | server |
+--------+ +--------+ +--------+
| | |
+-----1. Solicit(IA_LL)----->| |
| +----2. Relay-forward |
| | (Solicit(IA_LL),QUAD)------>|
| | |
| |<---3. Relay-reply |
| | (Advertise(IA_LL(LLADDR)))--+
|<4. Advertise(IA_LL(LLADDR))+ |
|-5. Request(IA_LL(LLADDR))->| |
| +-6. Relay-forward |
| | (Request(IA_LL(LLADDR)),QUAD)->|
| | |
| |<--7. Relay-reply |
| | (Reply(IA_LL(LLADDR)))-------+
|<--8. Reply(IA_LL(LLADDR))--+ |
| | |
. . .
. (timer expiring) .
. . .
| | |
+--9. Renew(IA_LL(LLADDR))-->| |
| |--10. Relay-forward |
| | (Renew(IA_LL(LLADDR)),QUAD)-->|
| | |
| |<---11. Relay-reply |
| | (Reply(IA_LL(LLADDR)))-----+
|<--12. Reply(IA_LL(LLADDR))-+ |
| | |
Figure 3: DHCPv6 Signaling Flow (Client-Relay-Server)
図3：DHCPv6シグナリングフロー（クライアントリレーサーバー）
1. Link-layer addresses (i.e., MAC 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 in the message. The IA_LL option MUST contain an LLADDR option.
1. リンク層アドレス（すなわち、MACアドレス）がブロック内で割り当てられる。最小ブロックは単一のアドレスです。割り当てを要求するために、クライアントはメッセージ内のIA_LLオプションを含む募話メッセージを送信します。IA_LLオプションにはLLADDRオプションが含まれている必要があります。
2. The DHCP relay receives the Solicit message and encapsulates it in a Relay-forward message. The relay, based on local knowledge and policies, includes in the Relay-forward message the QUAD option with the preferred quadrant. The relay might know which quadrant to request based on local configuration (e.g., the served network contains IoT devices only, thus requiring ELI/ SAI) or other means. Note that if a client sends multiple instances of the IA_LL option in the same message, the DHCP relay MAY only add a single instance of the QUAD option.
2. DHCPリレーは募集メッセージを受け取り、それをリレー転送メッセージにカプセル化します。ローカルの知識とポリシーに基づいて、リレーフォワードメッセージには、好ましい象限を持つクワッドオプションが含まれています。リレーは、ローカル構成に基づいて要求する象限がどの象限に基づいているか（例えば、サービス提供されたネットワークはIOTデバイスのみを含み、したがってELI / SAIを必要とする）または他の手段を知ることができる。クライアントが同じメッセージにIA_LLオプションの複数のインスタンスを送信すると、DHCPリレーはクワッドオプションの単一のインスタンスのみを追加することができます。
3. Upon receiving a relayed message containing an IA_LL option, the server inspects the contents for instances of OPTION_SLAP_QUAD in both the Relay-forward message and the client's message payload. Depending on the server's policy, the instance of the option to process is selected (see the end of this section). For each of the entries in OPTION_SLAP_QUAD, in order of the preference field (highest to lowest), the server checks if it has a configured MAC address pool matching the requested quadrant identifier and an available range of addresses of the requested size. If suitable addresses are found, the server sends back an Advertise message with an IA_LL option containing an LLADDR option that specifies the addresses being offered. This message is sent to the Relay in a Relay-reply message. If the server supports the semantics of the preferred quadrant included in the QUAD option and manages a block of addresses belonging to a requested quadrant, then the addresses being offered MUST belong to a requested quadrant. The server SHOULD apply the contents of the relay's supplied QUAD option for all of the client's IA_LLs, unless configured to do otherwise.
3. IA_LLオプションを含む中継メッセージを受信すると、サーバは、リレー転送メッセージとクライアントのメッセージペイロードの両方でoption_slap_quadのインスタンスの内容を検査します。サーバーのポリシーによっては、プロセスするオプションのインスタンスが選択されます（このセクションの最後を参照）。 Option_SLAP_QUADの各エントリについて、Preferenceフィールドの順に（最低から最小値まで）、サーバーは、要求された象限識別子と要求されたサイズの利用可能なアドレスの使用可能な範囲のMACアドレスプールがあるかどうかを確認します。適切なアドレスが見つかった場合、サーバーは、提供されているアドレスを指定するLLADDRオプションを含むIA_LLオプションを含むアドバタイズメッセージを送り返します。このメッセージはリレー返信メッセージの中継に送信されます。サーバーがクワッドオプションに含まれている好ましい象限の意味をサポートし、要求された象限に属するアドレスのブロックを管理している場合、提供されているアドレスは要求された象限に属していなければなりません。そうでなければ構成されていない限り、サーバーは、すべてのクライアントのIA_LLに対してRelayのQuadオプションの内容を適用する必要があります。
4. The relay sends the received Advertise message to the client.
4. リレーは受信したアドバタイズメッセージをクライアントに送信します。
5. 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.
5. クライアントは、[RFC8415]のセクション18.2.9で定義されているように、Advertise Responsesを送信し、1つのサーバーを選択するのを待ちます。その後、クライアントは、選択されたサーバーによって送信されたアドバタイズメッセージからコピーされたLLADDRオプションを含むIA_LLコンテナオプションを含む要求メッセージを送信します。
6. The relay forwards the received Request in a Relay-forward message. It adds, in the Relay-forward, a QUAD IA_LL option with the preferred quadrant.
6. リレーは受信した要求をリレー転送メッセージに転送します。それは、暫定象限を持つQuad IA_LLオプションをリレーフォワードに追加します。
7. Upon reception of the forwarded Request message with IA_LL container option, the server assigns requested addresses. The server MAY alter the allocation at this time. It then generates and sends a Reply message in a Relay-reply message back to the relay.
7. ia_ll containerオプションを使用して転送された要求メッセージを受信すると、サーバーは要求されたアドレスを割り当てます。このときサーバは割り当てを変更することができる。その後、Relay-Replyメッセージにリレイへの返信メッセージを生成してリレーに送信します。
8. Upon receiving a Reply message, the client parses the IA_LL container option and may start using all provided addresses.
8. 返信メッセージを受信すると、クライアントはIA_LLコンテナオプションを解析し、提供されているすべてのアドレスを使用して開始されます。
9. The client is expected to periodically renew the link-layer addresses, as governed by T1 and T2 timers. This mechanism can be administratively disabled by the server sending "infinity" as the T1 and T2 values (see Section 7.7 of [RFC8415]). The client sends a Renew option after T1.
9. T1およびT2のタイマによって管理されているように、クライアントはリンク層アドレスを定期的に更新することが期待されています。このメカニズムは、T1とT2の値として「Infinity」を送信するサーバーによって管理上無効にすることができます（[RFC8415]のセクション7.7を参照）。クライアントはT1の後に更新オプションを送信します。
10. This message is forwarded by the relay in a Relay-forward message, including a QUAD IA_LL option with the preferred quadrant.
10. このメッセージは、好ましい象限を持つクワッドIA_LLオプションを含む、リレー転送メッセージの中継によって転送されます。
11. The server responds with a Reply message, including an LLADDR option with extended lifetime. This message is sent in a Relay-reply message.
11. サーバーは、拡張された有効期間のLLADDRオプションを含む返信メッセージで応答します。このメッセージはRelay-Replyメッセージで送信されます。
12. The relay sends the Reply message back to the client.
12. リレーは返信メッセージをクライアントに送り返します。
The server SHOULD implement a configuration parameter to deal with the case where the client's DHCP message contains an instance of OPTION_SLAP_QUAD and the relay adds a second instance in its Relay-forward message. This parameter configures the server to process either the client's or the relay's instance of option QUAD. It is RECOMMENDED that the default for such a parameter is to process the client's instance of the option.
サーバーは、クライアントのDHCPメッセージにoption_slap_quadのインスタンスが含まれており、リレーはそのリレー転送メッセージに2番目のインスタンスを追加する場合に対処するための設定パラメータを実装する必要があります。このパラメータは、クライアントまたはリレーのオプションクワッドのインスタンスのいずれかを処理するようにサーバを構成します。そのようなパラメータのデフォルトは、クライアントのオプションのインスタンスを処理することをお勧めします。
The client MAY check if the received MAC address belongs to a quadrant it is willing to use/configure and MAY decide based on that whether to use/configure the received address.
クライアントは、受信したMACアドレスが象限に属しているかどうかを確認してもよく、受信したアドレスを使用/構成するかどうかに基づいて決定することができます。
The QUAD option is used to specify the preferences for the selected quadrants within an IA_LL. The option MUST be encapsulated either in the IA_LL-options field of an IA_LL option or in a Relay-forward message.
QUADオプションは、IA_LL内の選択された象限の環境設定を指定するために使用されます。このオプションは、IA_LLオプションまたはリレー転送メッセージのIA_LL-Optionsフィールドにカプセル化する必要があります。
The format of the QUAD option is:
quadオプションのフォーマットは次のとおりです。
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_SLAP_QUAD | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| quadrant-1 | pref-1 | quadrant-2 | pref-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| quadrant-n-1 | pref-n-1 | quadrant-n | pref-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: QUAD Option Format
図4：クワッドオプションフォーマット
option-code OPTION_SLAP_QUAD (140).
オプションコードOPTION_SLAP_QUAD（140）。
option-len 2 * number of included (quadrant, preference). This is a 2-byte field containing the total length of all (quadrant, preference) pairs included in the option.
Option-Len 2 *含まれている数（象限、嗜好）。これは、オプションに含まれるすべての（象限、嗜好）ペアの全長を含む2バイトのフィールドです。
quadrant-n Identifier of the quadrant (0: AAI, 1: ELI, 2: Reserved by IEEE [IEEEStd802c], and 3: SAI). Each quadrant MUST only appear once at most in the option. This is a 1-byte field.
Quadrant-N象限の識別子（0：AAI、1：ELI、2：IEEE [IEEESTD802C]、および3：SAI）。各象限は、オプションの中で一度だけ現れなければなりません。これは1バイトフィールドです。
pref-n Preference associated to quadrant-n. A higher value means a more preferred quadrant. This is a 1-byte field.
四分円-Nに関連したPREF-N設定。より高い値は、より好ましい象限を意味する。これは1バイトフィールドです。
A quadrant identifier value MUST only appear, at most, once in the option. If an option includes more than one occurrence of the same quadrant identifier, only the first occurrence is processed, and the rest MUST be ignored by the server.
象限識別子の値は、最大でオプションに1回だけ表示されます。オプションが同じ象限識別子の複数の出現を含む場合、最初の発生のみが処理され、残りはサーバーによって無視される必要があります。
If the same preference value is used for more than one quadrant, the server MAY select which quadrant should be preferred (if the server can assign addresses from all or some of the quadrants with the same assigned preference). Note that this is not a simple list of quadrants ordered by preference with no preference value, but a list of quadrants with explicit preference values. This way it can support the case whereby a client really has no preference between two or three quadrants, leaving the decision to the server.
同じ嗜好値が複数の象限に使用される場合、サーバはどの象限が好まれるべきかを選択することができる（サーバが同じ割り当て嗜好を有する象限の全部または一部からアドレスを割り当てることができる場合）。これは、好み値なしで順序付けされた象限の単純なリストではなく、明示的な嗜好値を持つ象限のリストです。このようにして、クライアントが本当に2つまたは3つの象限の間で好みを持っていない場合をサポートでき、その決定をサーバーに残します。
If the client or relay agent provides the OPTION_SLAP_QUAD, the server MUST use the quadrant-n/pref-n values to order the selection of the quadrants. If the server can provide an assignment from one of the specified quadrants, it SHOULD proceed with the assignment. If the server does not have a configured address pool matching any of the specified quadrant-n fields or if the server has a configured address pool of the correct quadrant but no available addresses, it MUST return the IA_LL option containing a status of NoAddrsAvail.
クライアントエージェントまたはリレーエージェントがOption_SLAP_QUADを提供する場合、サーバーは象限の選択を順序付けるためにQuadrant-N / Pref-N値を使用する必要があります。サーバーが指定された象限の1つから割り当てを提供できる場合は、割り当てを続行する必要があります。サーバーに、指定されたQUADRANT-Nフィールドのいずれかに設定されたアドレスプールが一致しない場合、またはサーバーに正しい象限の設定されたアドレスプールがあるが、利用可能なアドレスがない場合は、NoAddrSavailのステータスを含むIA_LLオプションを返す必要があります。
There is no requirement that the client or relay agent order the quadrant/pref values in any specific order; hence, servers MUST NOT assume that quadrant-1/pref-1 have the highest preference (except if there is only one set of values).
クライアントまたは中継エージェントが象限/ pref値を任意の特定の順序で順序付ける必要はありません。したがって、サーバーは、Quadrant-1 / Pref-1が最高の設定を持つと仮定してはいけません（値のセットのセットが1つしかない場合を除く）。
For cases where a server may not be configured to have pools for the client or relay quadrant preferences, clients and relays SHOULD specify all quadrants in the QUAD option to assure the client gets an address (or addresses) -- if any are available. Specifying all quadrants also results in a QUAD option supporting server responding like a non-QUAD option supporting server, i.e., an address (or addresses) from any available quadrants can be returned.
サーバーがクライアントまたは中継象限の環境設定のプールを設定できない場合には、クライアントとリレーはクワッドオプションですべての象限を指定して、クライアントがアドレス（またはアドレス）を取得することを保証します。すべての象限を指定すると、Quad Option Supporting Serverは、サーバー以外のサポートサーバー、すなわち、利用可能な象限からのアドレス（またはアドレス）を返すことができます。
IANA has assigned the QUAD (140) 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>で維持されている「IPv6（DHCPv6）」レジストリの「オプションコード」サブレクシストからクワッド（140）オプションコードを割り当てました。：
Value: 140 Description: OPTION_SLAP_QUAD Client ORO: No Singleton Option: Yes Reference: RFC 8948
値：140説明：option_slap_quadクライアントORO：いいえシングルトンオプション：はい参照：RFC 8948
See [RFC8415] and [RFC7227] for the DHCPv6 security and privacy considerations. See [RFC8200] for the IPv6 security considerations.
DHCPv6セキュリティとプライバシーの考慮事項については、[RFC8415]と[RFC7227]を参照してください。IPv6セキュリティ上の考慮事項については、[RFC8200]を参照してください。
Also, see [RFC8947] for security considerations regarding link-layer address assignments using DHCP.
また、DHCPを使用したリンク層アドレス割り当てに関するセキュリティ上の考慮事項については、[RFC8947]を参照してください。
[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>。
[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.、Sodelski、M.、Volz、B.、Yourtchenko、A.、Richardson、M.、Jiang、S.、Lemon、T.、T.Winters、「IPv6用動的ホスト構成プロトコル」（DHCPv6） "、RFC 8415、DOI 10.17487 / RFC8415、2018年11月、<https：//www.rfc-editor.org/info/rfc8415>。
[RFC8947] Volz, B., Mrugalski, T., and CJ. Bernardos, "Link-Layer Address Assignment Mechanism for DHCPv6", RFC 8947, DOI 10.17487/RFC8947, December 2020, <https://www.rfc-editor.org/info/rfc8947>.
[RFC8947] Volz、B.、Mrugalski、T.、およびCJ。Bernardos、「DHCPv6のリンク層アドレス割り当てメカニズム」、RFC 8947、DOI 10.17487 / RFC8947、2020年12月、<https：//www.rfc-editor.org/info/rfc8947>。
[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-2014, DOI 10.1109/IEEESTD.2014.6847097, June 2014, <https://doi.org/10.1109/IEEESTD.2014.6847097>.
[IEEESTD802] IEEE、「地元と首都圏ネットワークのIEEE規格：概要と建築」、IEEE STD 802-2014、DOI 10.1109 / IEEESTD.2014.6847097、2014年6月、<https：//doi.org/10.1109/ieeestd.2014.6847097>。
[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, August 2017, <https://doi.org/10.1109/IEEESTD.2017.8016709>.
[IEEESTD802C] IEEE、「地元と首都圏ネットワークのIEEE規格：概要と建築 - 改正2：地元の中アクセス制御（Mac）アドレス使用量」、IEEE STD 802C-2017、DOI 10.1109 / IEEESTD.2017.8016709、2017年8月、<https://doi.org/10.1109/ieeestd.2017.8016709>。
[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]ハンキン、D.、Mrugalski、T.、Sodelski、M.、Jiang、S.、およびS.クリシュナン、「新しい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.、Eresut、M.およびA.ケラネン、「拘束ノードネットワークのための用語」、RFC 7228、DOI 10.17487 / RFC 7228、2014年5月、<https：//www.rfc-editor.org/ info / rfc7228>。
[RFC7548] Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and A. Sehgal, "Management of Networks with Constrained Devices: Use Cases", RFC 7548, DOI 10.17487/RFC7548, May 2015, <https://www.rfc-editor.org/info/rfc7548>.
[RFC7548]、M.、ED。、Romascanu、D.、Schoenwaelder、J.、A.Sehgal、「制約付きデバイスを搭載したネットワークの管理：ユースケース」、RFC 7548、DOI 10.17487 / RFC7548、2015年5月、<https://www.rfc-editor.org/info/rfc7548>。
[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] The'th、S.およびR.hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https：//www.rfc-editor.org/ info / rfc8200>。
This appendix describes some examples of how the quadrant preference mechanisms could be used.
この付録では、象限嗜好メカニズムをどのように使用できるかのいくつかの例について説明します。
First, let's take an IoT scenario as an example. An IoT device might decide on its own the SLAP quadrant it wants to use to obtain a local MAC address, using the following information to make the decision:
まず、例としてIoTシナリオを取り上げましょう。IOTデバイスは、次の情報を使用して次の情報を使用して、ローカルMACアドレスを取得するために使用したいスラップ象限を独自に決定することができます。
* Type of IoT deployment: For example, industrial, domestic, rural, etc. For small deployments, such as domestic ones, the IoT device itself can decide to use the AAI quadrant (this might not even involve the use of DHCP, by the device just configuring a random address computed by the device itself). For large deployments, such as industrial or rural ones, where thousands of devices might coexist, the IoT can decide to use the ELI or SAI quadrants.
* IOTの展開の種類：例えば、国内のものなどの小さな展開のために、IoTデバイス自体はAAI象限を使用することを決定することができます（これは、DHCPの使用さえ、デバイスによるDHCPの使用も含まれない可能性があります）。デバイス自体によって計算されたランダムアドレスを設定するだけです。産業用または農村部などの大きな展開のために、何千もの装置が共存する可能性がある場合、IOTはELIまたはSAI象限を使用することを決定することができます。
* Mobility: If the IoT device can move, then it might prefer to select the SAI or AAI quadrants to minimize address collisions when moving to another network. If the device is known to remain fixed, then the ELI is probably the most suitable one to use.
* Mobility：IoTデバイスが移動できる場合は、別のネットワークに移動するときにアドレスの衝突を最小限に抑えるために、SAIまたはAAI象限を選択することをお勧めします。装置が固定されたままになっていることが知られている場合、ELIはおそらく使用するのが最も適したものです。
* Managed/Unmanaged: Depending on whether the IoT device is managed during its lifetime or cannot be reconfigured [RFC7548], the decision of what quadrant is more appropriate might be different. For example, if the IoT device can be managed (e.g., configured) and network topology changes might occur during its lifetime (e.g., due to changes on the deployment, such as extensions involving additional devices), this has an impact on the preferred quadrant (e.g., to avoid potential collisions in the future).
* 管理/管理されていないIOTデバイスがその有効期間中に管理されているか、または再設定できないかに応じて[RFC7548]、象限がより適切であることの決定は異なる場合があります。たとえば、IOTデバイスを管理することができ（たとえば、設定された）場合（たとえば、追加のデバイスを含む拡張などの展開などの展開の変更により）、これは優先象限に影響を与える可能性があります。（たとえば、将来の潜在的な衝突を回避するために）。
* Operation / Battery Lifetime: Depending on the expected lifetime of the device, a different quadrant might be preferred (as before, to minimize potential address collisions in the future).
* 操作/電池の寿命：デバイスの予想される寿命に応じて、異なる象限が優先される可能性があります（将来の潜在的なアドレスの衝突を最小限に抑えるために）。
The previous parameters are considerations that the device vendor/ administrator may wish to use when defining the IoT device's MAC address request policy (i.e., how to select a given SLAP quadrant). IoT devices are typically very resource constrained, so there may only be a simple decision-making process based on preconfigured preferences.
前のパラメータは、IOTデバイスのMACアドレス要求ポリシーを定義するときにデバイスベンダ/管理者が使用したいと思うことがあります（すなわち、特定のスラップ象限を選択する方法）。IOTデバイスは通常非常にリソースに制約されているので、事前設定された設定に基づく簡単な意思決定プロセスがある場合があります。
We now take the Wi-Fi device scenario, considering, for example, that a laptop or smartphone connects to a network using its built-in MAC address. Due to privacy/security concerns, the device might want to configure a local MAC address. The device might use different parameters and context information to decide, not only which SLAP quadrant to use for the local MAC address configuration, but also when to perform a change of address (e.g., it might be needed to change address several times). This information includes, but it is not limited to:
たとえば、ラップトップまたはスマートフォンが内蔵MACアドレスを使用してネットワークに接続することを検討して、Wi-Fiデバイスのシナリオを取ります。プライバシー/セキュリティの懸念のために、デバイスはローカルMACアドレスを設定したいと思うかもしれません。デバイスは、ローカルMACアドレス構成に使用するスラップ象限だけでなく、アドレスの変更を実行する場合（例えば、アドレスを数回変更するために必要とされる可能性がある場合は、）異なるパラメータとコンテキスト情報を使用することができます。この情報には含まれていますが、これに限定されません。
* Type of network the device is connected: public, work, home.
* ネットワークの種類デバイスが接続されている：Public、Work、Home。
* Trusted network: Yes/No.
* 信頼できるネットワーク：はい/いいえ。
* First time visited network: Yes/No.
* 初めてネットワークを訪問しました：はい/いいえ。
* Network geographical location.
* ネットワーク地理的な場所。
* Mobility: Yes (the device might change its network attachment point) / No (the device is not going to change its network attachment point).
* モビリティ：はい（デバイスがネットワーク接続ポイントを変更する可能性があります）/ NO（デバイスはネットワーク接続ポイントを変更しません）。
* Operating System (OS) network profile, including security/trust-related parameters: Most modern OSs keep metadata associated with the networks they can attach to as, for example, the level of trust the user or administrator assigns to the network. This information is used to configure how the device behaves in terms of advertising itself on the network, firewall settings, etc. But this information can also be used to decide whether or not to configure a local MAC address, from which SLAP quadrant it should be assigned, and how often it may be assigned.
* セキュリティ/信頼関連のパラメータを含むオペレーティングシステム（OS）ネットワークプロファイル：ほとんどの最近のOSSは、たとえば、ユーザーまたは管理者がネットワークに割り当てる信頼のレベルとして添付できるネットワークに関連付けられているメタデータを保持します。この情報は、ネットワーク、ファイアウォールの設定などの広告自体の観点からデバイスがどのように動作するかを設定するために使用されますが、この情報は、ローカルMABアドレスを構成するかどうかを決定するために使用できます。割り当てられた、そしてそれがどのくらいの頻度で割り当てられるか。
* Triggers coming from applications regarding location privacy: An app might request that the OS maximize location privacy (due to the nature of the application), and this might require the OS to force the use of a local MAC address or the local MAC address to be changed.
* 場所のプライバシーに関するアプリケーションからのトリガー：アプリは、OSが場所のプライバシーを最大化するように要求することがあります（アプリケーションの性質上）OSがローカルのMACアドレスまたはローカルMACアドレスの使用を強制する必要がある場合があります。かわった。
This information can be used by the device to select the SLAP quadrant. For example, if the device is moving around (e.g., while connected to a public network in an airport), it is likely that it might change access points several times; therefore, it is best to minimize the chances of address collision, using the SAI or AAI quadrants. If the device is not expected to move and is attached to a trusted network (e.g., in some scenarios at work), then it is probably best to select the ELI quadrant. These are just some examples of how to use this information to select the quadrant.
この情報は、スラップ象限を選択するためにデバイスによって使用されます。例えば、装置が移動している場合（例えば、空港内の公衆ネットワークに接続されている間）、それがアクセスポイントを数回変更する可能性がある可能性が高い。したがって、SAIまたはAAI象限を使用して、アドレス衝突の可能性を最小限に抑えることが最善です。デバイスが移動すると予想されず、信頼できるネットワークに接続されていない場合（例えば、作業中のいくつかのシナリオで）、それはおそらくELI象限を選択するのが最善です。これらは、この情報の使用方法のために象限を選択する方法のほんの一例です。
Additionally, the information can also be used to trigger subsequent changes of MAC address to enhance location privacy. Besides, changing the SLAP quadrant might also be used as an additional enhancement to make it harder to track the user location.
さらに、情報は、場所のプライバシーを強化するために、その後のMACアドレスの変更をトリガするためにも使用できます。その上、スラップ象限を変更することも、ユーザーの場所を追跡するのを難しくするための追加の機能強化としても使用されます。
Last, if we consider the data-center scenario, a hypervisor might request local MAC addresses be assigned to virtual machines. As in the previous scenarios, the hypervisor might select the preferred SLAP quadrant using information provided by the cloud management system or virtualization infrastructure manager running on top of the hypervisor. This information might include, but is not limited to:
最後に、データセンターのシナリオを検討した場合、ハイパーバイザーはローカルMACアドレスを仮想マシンに割り当てることを要求する可能性があります。以前のシナリオと同様に、ハイパーバイザーは、ハイパーバイザーの上部に実行されているクラウド管理システムまたは仮想化インフラストラクチャマネージャーによって提供される情報を使用して、優先スラップ象限を選択することがあります。この情報には以下が含まれますが、これらに限定されません。
* Migratable VM: If the function implemented by the VM is subject to be moved to another physical server or not, this has an impact on the preference for the SLAP quadrant, as the ELI and SAI quadrants are better suited for supporting migration in a large data center.
* Magratable VM：VMによって実装された関数が別の物理サーバーに移動されるかどうかにかかわらず、これは、LAPIおよびSAIの象限が大きなデータでの移行をサポートするために適しているため、これはスラップ象限の好みに影響を与えます。センター。
* VM connectivity characteristics: For example, standalone, part of a pool, and part of a service graph/chain. If the connectivity characteristics of the VM are known, this can be used by the hypervisor to select the best SLAP quadrant.
* VM接続特性：たとえば、スタンドアロン、プールの一部、およびサービスグラフ/チェーンの一部です。VMの接続特性が既知である場合、これはハイパーバイザーによって使用されて最高のスラップ象限を選択することができます。
Acknowledgments
謝辞
The authors would like to thank Bernie Volz for his very valuable comments on this document. We also want to thank Ian Farrer, Tomek Mrugalski, Éric Vyncke, Tatuya Jinmei, Carl Wallace, Ines Robles, Ted Lemon, Jaime Jimenez, Robert Wilton, Benjamin Kaduk, Barry Leiba, Alvaro Retana, and Murray Kucherawy for their very detailed and helpful reviews. And thanks to Roger Marks and Antonio de la Oliva for comments related to IEEE work and references.
この文書についての彼の非常に貴重なコメントのためにBernie Volzに感謝します。また、Ian Farrer、Tomek Mrugalski、ÉricVyncke、Tatuya Jinmei、Carl Wallace、Ines Robles、Ted Lemon、Jaime Jimenez、Robert Wilton、Benjamin Kaduk、Barry Leiba、Alvaro Retana、およびMurray Kucherawy、Murray Kucherawyレビュー。そして、IEEEの仕事や参照に関連するコメントについては、Roger MarksとAntonio de la Olivaに感謝します。
The work in this document has been supported by the H2020 5GROWTH (Grant 856709) and 5G-DIVE projects (Grant 859881).
この文書の作業は、H2020 5gth（Grant 856709）および5Gダイブプロジェクト（Grant 859881）によってサポートされています。
Authors' Addresses
著者の住所
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/
Alain Mourad InterDigital Europe
Alain Mourad Interdigital Europe
Email: Alain.Mourad@InterDigital.com
URI: http://www.InterDigital.com/