[要約] この文書は、デバイスが自己生成または静的に設定されたアドレスを持っていることをDHCPv6サーバーに通知する方法を定義しています。
Internet Engineering Task Force (IETF) W. Kumari
Request for Comments: 9686 Google, LLC
Category: Standards Track S. Krishnan
ISSN: 2070-1721 Cisco Systems, Inc.
R. Asati
Independent
L. Colitti
J. Linkova
Google, LLC
S. Jiang
BUPT
December 2024
This document defines a method to inform a DHCPv6 server that a device has one or more self-generated or statically configured addresses.
このドキュメントでは、DHCPV6サーバーに、デバイスに1つ以上の自己生成または静的に構成されたアドレスがあることを通知する方法を定義します。
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/rfc9686.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9686で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Conventions and Definitions
3. Registration Mechanism Overview
4. DHCPv6 Address Registration Procedure
4.1. DHCPv6 Address Registration Option
4.2. DHCPv6 Address Registration Request Message
4.2.1. Server Message Processing
4.3. DHCPv6 Address Registration Acknowledgement
4.4. Signaling Address Registration Support
4.5. Retransmission
4.6. Registration Expiry and Refresh
4.6.1. SLAAC Addresses
4.6.2. Statically Assigned Addresses
4.6.3. Transmitting Refreshes
5. Client Configuration
6. Security Considerations
7. Privacy Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
It is very common operational practice, especially in enterprise networks, to use IPv4 DHCP logs for troubleshooting or forensics purposes. An example of this includes a help desk dealing with a ticket such as "The CEO's laptop cannot connect to the printer"; if the Media Access Control (MAC) address of the printer is known (for example, from an inventory system), the printer's IPv4 address can be retrieved from the DHCP log or lease table and the printer can be pinged to determine if it is reachable. Another common example is a security operations team discovering suspicious events in outbound firewall logs and then consulting DHCP logs to determine which employee's laptop had that IPv4 address at that time so that they can quarantine it and remove the malware.
トラブルシューティングまたはフォレンジックの目的でIPv4 DHCPログを使用することは、特にエンタープライズネットワークで非常に一般的な運用慣行です。この例には、「CEOのラップトップはプリンターに接続できない」などのチケットを扱うヘルプデスクが含まれます。プリンターのメディアアクセス制御（MAC）アドレスが既知である場合（たとえば、インベントリシステムから）、プリンターのIPv4アドレスをDHCPログまたはリーステーブルから取得でき、プリンターをPingで到達できるかどうかを判断できます。。もう1つの一般的な例は、アウトバウンドファイアウォールログで疑わしいイベントを発見し、DHCPログに相談して、その時点でどの従業員のラップトップがそのIPv4アドレスを持っていたかを判断して、それを検疫してマルウェアを削除できるようにするセキュリティオペレーションチームです。
This operational practice relies on the DHCP server knowing the IP address assignments. This works quite well for IPv4 addresses, as most addresses are either assigned by DHCP [RFC2131] or statically configured by the network operator. For IPv6, however, this practice is much harder to implement, as devices often self-configure IPv6 addresses via Stateless Address Autoconfiguration (SLAAC) [RFC4862].
この運用慣行は、IPアドレスの割り当てを知っているDHCPサーバーに依存しています。ほとんどのアドレスはDHCP [RFC2131]によって割り当てられているか、ネットワークオペレーターによって静的に構成されているため、これはIPv4アドレスで非常にうまく機能します。ただし、IPv6の場合、このプラクティスは実装するのがはるかに困難です。これは、DevicesがStateless Address Autoconfiguration（SLAAC）[RFC4862]を介して自己構成されることが多いため、実装がはるかに困難です。
This document provides a mechanism for a device to inform the DHCPv6 server that the device has a self-configured IPv6 address (or has a statically configured address), and thus provides parity with IPv4 by making DHCPv6 infrastructure aware of self-assigned IPv6 addresses.
このドキュメントは、デバイスにDHCPV6サーバーに、デバイスに自己構成のIPv6アドレスがあること（または静的に構成されたアドレスがある）を通知するメカニズムを提供し、したがって、DHCPV6インフラストラクチャに自己割り当てされたIPv6アドレスを認識することによりIPv4のパリティを提供します。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The DHCPv6 protocol is used as the address registration protocol and a DHCPv6 server performs the role of an address registration server. This document introduces a new Address Registration (OPTION_ADDR_REG_ENABLE) option, which indicates that the server supports the registration mechanism. Before registering any addresses, the client MUST determine whether the network supports address registration. It can do this by including the Address Registration option code in the Option Request option (see Section 21.7 of [RFC8415]) of the Information-Request, Solicit, Request, Renew, or Rebind messages it sends to the server as part of the regular stateless or stateful DHCPv6 configuration process. If the server supports address registration, it includes an Address Registration option in its Advertise or Reply messages. To avoid undesired multicast traffic, if the DHCPv6 infrastructure does not support (or is not willing to receive) any address registration information, the client MUST NOT register any addresses using the mechanism in this specification. Otherwise, the client registers addresses as described below.
DHCPV6プロトコルはアドレス登録プロトコルとして使用され、DHCPV6サーバーはアドレス登録サーバーの役割を実行します。このドキュメントでは、新しいアドレス登録（option_addr_reg_enable）オプションを紹介します。これは、サーバーが登録メカニズムをサポートしていることを示します。アドレスを登録する前に、クライアントはネットワークがアドレス登録をサポートするかどうかを判断する必要があります。これは、情報の要求、勧誘、要求、更新、または通常の一部としてサーバーに送信するメッセージの一部の登録オプションコード（[RFC8415]のセクション21.7を参照[RFC8415]を参照）を含めることで行うことができます。ステートレスまたはステートフルなDHCPV6構成プロセス。サーバーがアドレス登録をサポートしている場合、アドレス登録オプションが広告または返信メッセージに含まれています。望ましくないマルチキャストトラフィックを避けるために、DHCPV6インフラストラクチャがアドレス登録情報をサポートしていない（または受け取る意思がない）場合、クライアントはこの仕様のメカニズムを使用してアドレスを登録してはなりません。それ以外の場合、クライアントは以下に説明するようにアドレスを登録します。
After successfully assigning a self-generated or statically configured valid IPv6 address [RFC4862] on one of its interfaces, a client implementing this specification multicasts an ADDR-REG-INFORM message (see Section 4.2) in order to inform the DHCPv6 server that this self-generated address is in use. Each ADDR-REG-INFORM message contains a DHCPv6 Identity Association (IA) Address option [RFC8415] to specify the address being registered.
自己生成または静的に構成された有効なIPv6アドレス[RFC4862]をそのインターフェイスの1つに割り当てた後、この仕様を実装するクライアントは、DHCPV6サーバーにこの自己を通知するために、AddR-Reg-Informメッセージ（セクション4.2を参照）を実装します（セクション4.2を参照）- 生成されたアドレスが使用されています。各addr-reg-informメッセージには、登録されているアドレスを指定するために、DHCPV6アイデンティティアソシエーション（IA）アドレスオプション[RFC8415]が含まれています。
The address registration mechanism overview is shown in Figure 1.
アドレス登録メカニズムの概要を図1に示します。
+--------+ +------------------+ +---------------+
| CLIENT | | FIRST-HOP ROUTER | | DHCPv6 SERVER |
+--------+ +---------+--------+ +-------+-------+
| SLAAC | |
|<--------------------> | |
| | |
| |
| src: link-local address |
| --------------------------------------------> |
| INFORMATION-REQUEST or SOLICIT/... |
| - OPTION REQUEST OPTION |
| -- OPTION_ADDR_REG_ENABLE |
| |
| ... |
| |
| |
|<--------------------------------------------- |
| REPLY or ADVERTISE MESSAGE |
| - OPTION_ADDR_REG_ENABLE |
| |
| |
| src: address being registered |
| --------------------------------------------> |
| ADDR-REG-INFORM MESSAGE |Register/
| |log addresses
| |
| |
| <-------------------------------------------- |
| ADDR-REG-REPLY MESSAGE |
| |
Figure 1: Address Registration Procedure Overview
図1：アドレス登録手順の概要
The Address Registration option (OPTION_ADDR_REG_ENABLE) indicates that the server supports the mechanism described in this document. The format of the Address Registration option is described as follows:
アドレス登録オプション（option_addr_reg_enable）は、サーバーがこのドキュメントで説明されているメカニズムをサポートしていることを示します。アドレス登録オプションの形式は次のように説明されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: DHCPv6 Address Registration Option
図2：DHCPV6アドレス登録オプション
option-code:
オプションコード：
OPTION_ADDR_REG_ENABLE (148)
option_addr_reg_enable（148）
option-len:
オプションレン：
0
0
If a client has the address registration mechanism enabled, it MUST include this option in all Option Request options that it sends.
クライアントがアドレス登録メカニズムを有効にしている場合、送信するすべてのオプション要求オプションにこのオプションを含める必要があります。
A server that is configured to support the address registration mechanism MUST include this option in Advertise and Reply messages if the client message it is replying to contained this option in the Option Request option.
アドレス登録メカニズムをサポートするように構成されているサーバーは、このオプションをAdvertiseメッセージに含める必要があります。
The DHCPv6 client sends an ADDR-REG-INFORM message to inform that an IPv6 address is assigned to the client's interface. The format of the ADDR-REG-INFORM message is described as follows:
DHCPV6クライアントは、IPv6アドレスがクライアントのインターフェイスに割り当てられていることを通知するために、addr-reg-informメッセージを送信します。Addr-Reg-Informメッセージの形式は、次のように説明されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | transaction-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. options .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DHCPv6 ADDR-REG-INFORM Message
図3：DHCPV6 Addr-Reg-Informメッセージ
msg-type:
MSGタイプ：
Identifies the DHCPv6 message type; set to ADDR-REG-INFORM (36).
DHCPV6メッセージタイプを識別します。Addr-Reg-Inform（36）に設定します。
transaction-id:
Transaction-ID：
The transaction ID for this message exchange.
このメッセージ交換のトランザクションID。
options:
オプション：
The options carried in this message.
このメッセージに掲載されたオプション。
The client MUST generate a transaction ID as described in [RFC8415] and insert this value in the transaction-id field.
[RFC8415]で説明されているように、クライアントはトランザクションIDを生成し、この値をトランザクション-IDフィールドに挿入する必要があります。
The client MUST include the Client Identifier option [RFC8415] in the ADDR-REG-INFORM message.
クライアントは、addr-reg-informメッセージにクライアント識別子オプション[RFC8415]を含める必要があります。
The ADDR-REG-INFORM message MUST NOT contain the Server Identifier option and MUST contain exactly one IA Address option containing the address being registered. The valid-lifetime and preferred-lifetime fields in the option MUST match the current Valid Lifetime and Preferred Lifetime of the address being registered.
AddR-Reg-Informメッセージには、サーバー識別子オプションが含まれていない必要があり、登録されているアドレスを含む1つのIAアドレスオプションを正確に含める必要があります。オプション内の有効なリフェティタイムおよび優先ライフタイムフィールドは、登録されているアドレスの現在の有効な寿命と優先寿命と一致する必要があります。
The ADDR-REG-INFORM message is dedicated for clients to initiate an address registration request toward an address registration server. Consequently, clients MUST NOT put any Option Request option(s) in the ADDR-REG-INFORM message. Clients MAY include other options, such as the Client FQDN option [RFC4704].
Addr-Reg-Informメッセージは、クライアントがアドレス登録要求をアドレス登録サーバーに向けて開始するために専用です。したがって、クライアントはAddR-Reg-Informメッセージにオプションリクエストオプションを配置してはなりません。クライアントには、クライアントFQDNオプション[RFC4704]など、他のオプションが含まれる場合があります。
The client sends the DHCPv6 ADDR-REG-INFORM message to the All_DHCP_Relay_Agents_and_Servers multicast address (ff02::1:2). The client MUST send separate messages for each address being registered.
クライアントは、dhcpv6 addr-reg-informメッセージをAll_dhcp_relay_agents_and_serversマルチキャストアドレス（FF02 :: 1：2）に送信します。クライアントは、登録されているアドレスごとに個別のメッセージを送信する必要があります。
Unlike other types of messages, which are sent from the link-local address of the client, the ADDR-REG-INFORM message MUST be sent from the address being registered. This is primarily for "fate sharing" purposes; for example, if the network implements some form of Layer 2 security to prevent a client from spoofing other clients' MAC addresses, this prevents an attacker from spoofing ADDR-REG-INFORM messages.
クライアントのLink-Localアドレスから送信される他のタイプのメッセージとは異なり、登録されているアドレスからADDR-REG-INFOLTメッセージを送信する必要があります。これは主に「運命共有」の目的のためです。たとえば、ネットワークが何らかの形のレイヤー2セキュリティを実装して、クライアントが他のクライアントのMACアドレスを呼び起こさないようにする場合、攻撃者がAddr-Reg-Informメッセージをスプーフィングすることを防ぎます。
On clients with multiple interfaces, the client MUST only send the packet on the network interface that has the address being registered, even if it has multiple interfaces with different addresses. If the same address is configured on multiple interfaces, then the client MUST send the ADDR-REG-INFORM message each time the address is configured on an interface that did not previously have it and refresh each registration independently from the others.
複数のインターフェイスを備えたクライアントでは、クライアントは、異なるアドレスを持つ複数のインターフェイスがある場合でも、登録されているネットワークインターフェイスにパケットを送信する必要があります。同じアドレスが複数のインターフェイスで構成されている場合、アドレスが以前にそれを持っていなかったインターフェイスで構成され、他の登録を独立して各登録を更新するたびに、クライアントはAddR-Reg-Informメッセージを送信する必要があります。
The client MUST only send the ADDR-REG-INFORM message for valid addresses [RFC4862] of global scope [RFC4007]. This includes Unique Local Addresses (ULAs), which are defined in [RFC4193] to have global scope. This also includes statically assigned addresses of global scope (such addresses are considered to be valid indefinitely). The client MUST NOT send the ADDR-REG-INFORM message for addresses configured by DHCPv6.
クライアントは、グローバルスコープ[RFC4007]の有効なアドレス[RFC4862]に対してAddR-Reg-Informメッセージを送信する必要があります。これには、グローバルな範囲を持つために[RFC4193]で定義されている一意のローカルアドレス（ULAS）が含まれます。これには、グローバルスコープの静的に割り当てられたアドレスも含まれます（このようなアドレスは無期限に有効であると見なされます）。クライアントは、DHCPV6によって構成されたアドレスのADDR-REG-INFOLTメッセージを送信してはなりません。
The client SHOULD NOT send the ADDR-REG-INFORM message unless it has received a Router Advertisement (RA) message with either the M or O flags set to 1.
クライアントは、1に設定されたMまたはOフラグのいずれかを使用してルーター広告（RA）メッセージを受信しない限り、ADDR-REG-INFOLDメッセージを送信しないでください。
Clients MUST discard any received ADDR-REG-INFORM messages.
クライアントは、受信したAddR-Reg-Informメッセージを破棄する必要があります。
Servers MUST discard any ADDR-REG-INFORM messages that meet any of the following conditions:
サーバーは、次の条件のいずれかを満たすAddr-Reg-Informメッセージを破棄する必要があります。
* the message does not include a Client Identifier option;
* メッセージには、クライアント識別子オプションは含まれていません。
* the message includes a Server Identifier option;
* メッセージには、サーバー識別子オプションが含まれます。
* the message does not include the IA Address option, or the IP address in the IA Address option does not match the source address of the original ADDR-REG-INFORM message sent by the client. The source address of the original message is the source IP address of the packet if it is not relayed or is the peer-address field of the innermost Relay-forward message if it is relayed; or
* メッセージにはIAアドレスオプションが含まれていません。または、IAアドレスオプションのIPアドレスは、クライアントが送信した元のAddR-Reg-Informメッセージのソースアドレスと一致しません。元のメッセージのソースアドレスは、リレーされていない場合のパケットのソースIPアドレス、またはリレーされている場合の最も内側のリレーフォワードメッセージのピアアドレスフィールドです。または
* the message includes an Option Request option.
* メッセージには、オプションリクエストオプションが含まれています。
If the message is not discarded, the address registration server SHOULD verify that the address being registered is "appropriate to the link" as defined by [RFC8415] or within a prefix delegated to the client via DHCPv6 for Prefix Delegation (DHCPv6-PD) (see Section 6.3 of [RFC8415]). If the address being registered fails this verification, the server MUST drop the message and SHOULD log this fact. If the message passes the verification, the server:
メッセージが破棄されていない場合、アドレス登録サーバーは、登録されているアドレスが[RFC8415]で定義されているように「リンクに適している」、またはプレフィックス委任のためにDHCPV6を介してクライアントに委任されたプレフィックス内で「リンクに適している」ことを確認する必要があります（DHCPV6-PD）（[RFC8415]のセクション6.3を参照してください。登録されているアドレスがこの検証に失敗した場合、サーバーはメッセージをドロップする必要があり、この事実を記録する必要があります。メッセージが検証を渡す場合、サーバー：
* MUST log the address registration information (as is done normally for clients to which it has assigned an address), unless it is configured not to do so. The server SHOULD log the client DHCP Unique Identifier (DUID) and the link-layer address, if available. The server MAY log any other information.
* アドレス登録情報を記録する必要があります（アドレスを割り当てたクライアントに対して通常行われます）。サーバーは、利用可能な場合は、クライアントDHCP一意の識別子（DUID）とリンク層アドレスを記録する必要があります。サーバーは、他の情報を記録する場合があります。
* SHOULD register a binding between the provided Client Identifier and IPv6 address in its database, if no binding exists. The lifetime of the binding is equal to the Valid Lifetime of the address reported by the client. If there is already a binding between the registered address and the same client, the server MUST update its lifetime. If there is already a binding between the registered address and another client, the server SHOULD log the fact and update the binding.
* バインディングが存在しない場合は、データベースに提供されたクライアント識別子とIPv6アドレスの間にバインディングを登録する必要があります。バインディングの寿命は、クライアントが報告したアドレスの有効な寿命に等しくなります。登録されたアドレスと同じクライアントの間にすでに拘束力がある場合、サーバーはその寿命を更新する必要があります。登録アドレスと別のクライアントの間に既にバインディングがある場合、サーバーは事実を記録し、バインディングを更新する必要があります。
* SHOULD mark the address as unavailable for use and not include it in future Advertise messages.
* アドレスを使用することはできないとマークし、将来の広告メッセージに含めないでください。
* MUST send back an ADDR-REG-REPLY message to ensure the client does not retransmit.
* クライアントが再送信されないようにするために、AddR-Reg-Replyメッセージを送り返す必要があります。
If a client is multihomed (i.e., connected to multiple administrative domains, each operating its own DHCPv6 infrastructure), the requirement to verify that the registered address is appropriate for the link or belongs to a delegated prefix ensures that each DHCPv6 server only registers bindings for addresses from the given administrative domain.
クライアントがマルチホーム（つまり、複数の管理ドメインに接続され、それぞれが独自のDHCPV6インフラストラクチャに接続されている場合）の場合、登録アドレスがリンクに適しているか、委任されたプレフィックスに属していることを確認する要件は、各DHCPV6サーバーのみを保証することを保証します。指定された管理ドメインからのアドレス。
As mentioned in Section 4.2, although a client "MUST NOT send the ADDR-REG-INFORM message for addresses configured by DHCPv6", if a server does receive such a message, it SHOULD log and discard it.
セクション4.2で述べたように、クライアントは「DHCPV6で構成されたアドレスのADDR-REG-INFOLTメッセージを送信してはなりません」が、サーバーがそのようなメッセージを受信した場合、ログと破棄する必要があります。
DHCPv6 relay agents and switches that relay address registration messages directly from clients MUST include the client's link-layer address in the relayed message using the Client Link-Layer Address option [RFC6939] if they would do so for other DHCPv6 client messages such as Solicit, Request, and Rebind.
DHCPV6リレーエージェントとリレーアドレス登録メッセージをクライアントから直接スイッチする必要があります。クライアントリンクレイヤーアドレスオプション[RFC6939]を使用して、クライアントのリンクレイヤーアドレスをリレーしたメッセージに含める必要があります。リクエスト、そして逆にします。
The server MUST acknowledge receipt of a valid ADDR-REG-INFORM message by sending back an ADDR-REG-REPLY message. The format of the ADDR-REG-REPLY message is described as follows:
サーバーは、addr-reg-replyメッセージを返送して、有効なaddr-reg-informメッセージの受信を確認する必要があります。Addr-Reg-Replyメッセージの形式は、次のように説明されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | transaction-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. options .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: DHCPv6 ADDR-REG-REPLY Message
図4：DHCPV6 Addr-Reg-Replyメッセージ
msg-type:
MSGタイプ：
Identifies the DHCPv6 message type; set to ADDR-REG-REPLY (37).
DHCPV6メッセージタイプを識別します。Addr-Reg-Reply（37）に設定します。
transaction-id:
Transaction-ID：
The transaction ID for this message exchange.
このメッセージ交換のトランザクションID。
options:
オプション：
The options carried in this message.
このメッセージに掲載されたオプション。
If the ADDR-REG-INFORM message that the server is replying to was not relayed, then the IPv6 destination address of the message MUST be the address being registered. If the ADDR-REG-INFORM message was relayed, then the server MUST construct the Relay-reply message as specified in Section 19.3 of [RFC8415].
サーバーが返信しているAddR-Reg-Informメッセージが中継されていない場合、メッセージのIPv6宛先アドレスは登録されているアドレスでなければなりません。addr-reg-informメッセージがリレーされた場合、[RFC8415]のセクション19.3で指定されているように、サーバーはリレー無応メッセージを構築する必要があります。
The server MUST copy the transaction-id from the ADDR-REG-INFORM message to the transaction-id field of the ADDR-REG-REPLY.
サーバーは、Transaction-IDをADDR-REG-INFORMメッセージからAddR-Reg-ReplyのトランザクションIDフィールドにコピーする必要があります。
The ADDR-REG-REPLY message MUST contain an IA Address option for the address being registered. The option MUST be identical to the one in the ADDR-REG-INFORM message that the server is replying to.
AddR-Reg-Replyメッセージには、登録されているアドレスのIAアドレスオプションを含める必要があります。このオプションは、サーバーが返信しているAddr-Reg-Informメッセージのものと同一でなければなりません。
Servers MUST ignore any received ADDR-REG-REPLY messages.
サーバーは、受信したAddR-Reg-Replyメッセージを無視する必要があります。
Clients MUST discard any ADDR-REG-REPLY messages that meet any of the following conditions:
クライアントは、次の条件のいずれかを満たすADDR-REGREPLYメッセージを破棄する必要があります。
* the IPv6 destination address does not match the address being registered;
* IPv6宛先アドレスは、登録されているアドレスと一致しません。
* the IA Address option does not match the address being registered;
* IAアドレスオプションは、登録されているアドレスと一致しません。
* the address being registered is not assigned to the interface receiving the message; or
* 登録されているアドレスは、メッセージを受信するインターフェイスに割り当てられていません。または
* the transaction-id does not match the transaction-id the client used in the corresponding ADDR-REG-INFORM message.
* Transaction-IDは、クライアントが対応するAddR-Reg-Informメッセージで使用したトランザクションIDと一致しません。
The ADDR-REG-REPLY message only indicates that the ADDR-REG-INFORM message has been received and that the client should not retransmit it. The ADDR-REG-REPLY message MUST NOT be considered to be any indication of the address validity and MUST NOT be required for the address to be usable. DHCPv6 relays, or other devices that snoop ADDR-REG-REPLY messages, MUST NOT add or alter any forwarding or security state based on the ADDR-REG-REPLY message.
Addr-Reg-Replyメッセージは、Addr-Reg-Informメッセージが受信され、クライアントがそれを再送信してはならないことを示しています。Addr-Reg-Replyメッセージは、アドレスの有効性の兆候であると見なされてはなりません。また、アドレスを使用できるようにするには必須であってはなりません。DHCPV6リレー、またはAddR-Reg-ReplyメッセージをSnoopである他のデバイスは、AddR-Reg-Replyメッセージに基づいて転送またはセキュリティ状態を追加または変更してはなりません。
To avoid undesired multicast traffic, the client MUST NOT register addresses using this mechanism unless the DHCPv6 infrastructure supports address registration. The client can discover this by including the OPTION_ADDR_REG_ENABLE option in the Option Request options that it sends. If the client receives and processes an Advertise or Reply message with the OPTION_ADDR_REG_ENABLE option, it concludes that the DHCPv6 infrastructure supports address registration. When the client detects address registration support, it MUST start the registration process (unless configured not to do so) and MUST immediately register any addresses that are already in use. Once the client starts the registration process, it MUST NOT stop registering addresses until it disconnects from the link, even if subsequent Advertise or Reply messages do not contain the OPTION_ADDR_REG_ENABLE option.
望ましくないマルチキャストトラフィックを回避するために、DHCPV6インフラストラクチャがアドレス登録をサポートしていない限り、クライアントはこのメカニズムを使用してアドレスを登録してはなりません。クライアントは、送信するオプションリクエストオプションにoption_addr_reg_enableオプションを含めることでこれを発見できます。クライアントがOption_Addr_Reg_Enableオプションを使用して広告または返信メッセージを受信および処理する場合、DHCPV6インフラストラクチャがアドレス登録をサポートしていると結論付けます。クライアントがアドレス登録サポートを検出した場合、登録プロセスを開始する必要があります（そうしないように構成されていない限り）。既に使用されているアドレスをすぐに登録する必要があります。クライアントが登録プロセスを開始したら、後続の広告または返信メッセージにoption_addr_reg_enableオプションが含まれていない場合でも、リンクから切断されるまでアドレスの登録を停止しないでください。
The client MUST discover whether the DHCPv6 infrastructure supports address registration every time it connects to a network or when it detects it has moved to a new link, without utilizing any prior knowledge about address registration support on that network or link. This client behavior allows networks to progressively roll out support for the Address Registration option across the DHCPv6 infrastructure without causing clients to frequently stop and restart address registration if some of the network's DHCPv6 servers support it and some do not.
クライアントは、DHCPV6インフラストラクチャがネットワークに接続するたびにアドレス登録をサポートしているかどうか、またはそのネットワークまたはリンクのアドレス登録サポートに関する事前知識を利用せずに、新しいリンクに移動した場合に住所登録をサポートするかどうかを発見する必要があります。このクライアントの動作により、ネットワークのDHCPV6サーバーの一部がサポートしていない場合、クライアントが頻繁に停止し、アドレス登録を再起動することなく、DHCPV6インフラストラクチャ全体のアドレス登録オプションのサポートを徐々にロールアウトできます。
A client with multiple interfaces MUST discover address registration support for each interface independently. The client MUST NOT send address registration messages on a given interface unless the client has discovered that the interface is connected to a network that supports address registration.
複数のインターフェイスを備えたクライアントは、各インターフェイスのアドレス登録サポートを個別に発見する必要があります。クライアントは、インターフェイスがアドレス登録をサポートするネットワークに接続されていることをクライアントが発見しない限り、特定のインターフェイスにアドレス登録メッセージを送信してはなりません。
To reduce the effects of packet loss on registration, the client MUST retransmit the registration message. Retransmissions SHOULD follow the standard retransmission logic specified by Section 15 of [RFC8415] with the following default parameters for the initial retransmission time (IRT) and maximum retransmission count (MRC):
登録に対するパケット損失の影響を減らすために、クライアントは登録メッセージを再送信する必要があります。再送信は、[RFC8415]のセクション15で指定された標準の再送信ロジックに従って、初期再送信時間（IRT）および最大再送信数（MRC）の次のデフォルトパラメーターを使用する必要があります。
* IRT 1 sec
* IRT 1秒
* MRC 3
* MRC 3
The client SHOULD allow these parameters to be configured by the administrator.
クライアントは、これらのパラメーターを管理者によって構成することを許可する必要があります。
To comply with Section 16.1 of [RFC8415], the client MUST leave the transaction ID unchanged in retransmissions of an ADDR-REG-INFORM message. When the client retransmits the registration message, the lifetimes in the packet MUST be updated so that they match the current lifetimes of the address.
[RFC8415]のセクション16.1に準拠するには、クライアントは、AddR-Reg-Informメッセージの再送信に変更されていないままにしておく必要があります。クライアントが登録メッセージを再送信するとき、パケットの寿命を更新して、アドレスの現在の寿命と一致するようにする必要があります。
If an ADDR-REG-REPLY message is received for the address being registered, the client MUST stop retransmission.
登録されているアドレスに対してADDR-REGREPLYメッセージが受信された場合、クライアントは再送信を停止する必要があります。
The client MUST refresh registrations to ensure that the server is always aware of which addresses are still valid. The client SHOULD perform refreshes as described below.
クライアントは、サーバーが常に有効であることをサーバーが常に認識していることを確認するために登録を更新する必要があります。クライアントは、以下に説明するようにリフレッシュを実行する必要があります。
For an address configured using SLAAC, a function AddrRegRefreshInterval(address) is defined as 80% of the address's current Valid Lifetime. When calculating this value, the client applies a multiplier of AddrRegDesyncMultiplier to avoid synchronization with other clients, which could cause a large number of registration messages to reach the server at the same time. AddrRegDesyncMultiplier is a random value uniformly distributed between 0.9 and 1.1 (inclusive) and is chosen by the client when it starts the registration process, to ensure that refreshes for addresses with the same lifetime are coalesced (see below).
SLAACを使用して構成されたアドレスの場合、関数addRregrefreshinterval（アドレス）は、アドレスの現在の有効な寿命の80％として定義されます。この値を計算するとき、クライアントは他のクライアントとの同期を避けるためにAddRregdesyncMultiplierの乗数を適用します。AddRregdesyncMultiplierは、0.9から1.1（包括的）の間に均一に分布したランダムな値であり、登録プロセスを開始するときにクライアントによって選択され、同じ寿命の住所のリフレッシュが合体されていることを確認します（以下を参照）。
Whenever the client registers or refreshes an address, it calculates a NextAddrRegRefreshTime for that address as AddrRegRefreshInterval seconds in the future but does not schedule any refreshes.
クライアントがアドレスを登録またはリフレッシュするたびに、そのアドレスのnextddrregrefreshtimeを将来addRregrefreshinterval秒として計算しますが、リフレッシュをスケジュールしません。
Whenever the network changes the Valid Lifetime of an existing address by more than 1%, for example, by sending a Prefix Information Option (PIO) [RFC4861] with a new Valid Lifetime, the client calculates a new AddrRegRefreshInterval. The client schedules a refresh for min(now + AddrRegRefreshInterval, NextAddrRegRefreshTime). If the refresh would be scheduled in the past, then the refresh occurs immediately.
ネットワークが既存のアドレスの有効な寿命を1％以上変更するときはいつでも、たとえば、新しい有効な寿命でプレフィックス情報オプション（PIO）[RFC4861]を送信することにより、クライアントは新しいAddRregrefreshintervalを計算します。クライアントはMinの更新をスケジュールします（Now + AddRregrefreshinterval、NextDdrregrefreshtime）。過去に更新がスケジュールされる場合、更新はすぐに発生します。
Justification: This algorithm ensures that refreshes are not sent too frequently while ensuring that the server never believes that the address has expired when it has not. Specifically, after every registration:
正当化：このアルゴリズムは、リフレッシュがあまり頻繁に送信されないことを保証しますが、サーバーが住所がないときに期限切れになっていると信じていないことを保証します。具体的には、すべての登録の後：
* If the network never changes the lifetime of an address (e.g., if no further PIOs are received, or if all PIO lifetimes decrease in step with the passage of time), then no refreshes occur. Refreshes are not necessary, because the address expires at the time the server expects it to expire.
* ネットワークがアドレスの寿命を変更しない場合（たとえば、それ以上のPIOが受信されない場合、またはすべてのPIO寿命が時間の経過とともにステップが減少する場合）、リフレッシュは発生しません。サーバーが期限切れになると予想している時点でアドレスの有効期限が切れるため、リフレッシュは必要ありません。
* Any time the network changes the lifetime of an address (i.e., changes the time at which the address will expire), the client ensures that a refresh is scheduled, so that server will be informed of the new expiry.
* ネットワークがアドレスの寿命を変更すると（つまり、アドレスが期限切れになる時間を変更します）、クライアントは更新がスケジュールされることを保証し、サーバーに新しい有効期限を通知します。
* Because AddrRegDesyncMultiplier is at most 1.1, the refresh never occurs later than a point 88% between the time when the address was registered and the time when the address will expire. This allows the client to retransmit the registration for up to 12% of the original interval before it expires. This may not be possible if the network sends a Router Advertisement (RA) [RFC4861] very close to the time when the address would have expired. In this case, the client refreshes immediately, which is the best it can do.
* AddRregdesyncMultiplierは最大1.1であるため、住所が登録された時からアドレスが期限切れになるまでの間に、リフレッシュはポイント88％よりも遅くなることはありません。これにより、クライアントは有効期限が切れる前に元の間隔の最大12％の登録を再送信できます。これは、ネットワークがルーター広告（RA）[RFC4861]を送信して、アドレスの有効期限が切れていた場合には不可能です。この場合、クライアントはすぐにリフレッシュしますが、これはできる最善です。
* The 1% tolerance ensures that the client will not refresh or reschedule refreshes if the Valid Lifetime experiences minor changes due to transmission delays or clock skew between the client and the router(s) sending the RA.
* 1％の耐性により、有効な寿命がクライアントとルーターがRAを送信するルーターの間の伝送の遅延または時計歪みのために軽微な変更を経験した場合、クライアントが更新または再スケジュールを再スケジュールしないようにします。
* AddrRegRefreshCoalesce (Section 4.6.3) allows battery-powered clients to wake up less often. In particular, it allows the client to coalesce refreshes for multiple addresses formed from the same prefix, such as the stable and privacy addresses. Higher values will result in fewer wakeups but may result in more network traffic, because if a refresh is sent early, then the next RA received will cause the client to immediately send a refresh message.
* AddRregrefreshcoalesce（セクション4.6.3）により、バッテリー駆動のクライアントは頻繁に目を覚ますことができます。特に、クライアントは、安定したアドレスやプライバシーアドレスなど、同じプレフィックスから形成された複数のアドレスのリフレッシュを合体化できます。値が高いとウェイクアップが少なくなりますが、ネットワークトラフィックが増える可能性があります。これは、更新が早めに送信された場合、次のRAが受信するとクライアントがすぐに更新メッセージを送信するためです。
* In typical networks, the lifetimes in periodic RAs either contain constant values or values that decrease over time to match another lifetime, such as the lifetime of a prefix delegated to the network. In both these cases, this algorithm will refresh on the order of once per address lifetime, which is similar to the number of refreshes that are necessary using stateful DHCPv6.
* 典型的なネットワークでは、周期的なRAの寿命には、ネットワークに委任されたプレフィックスの寿命など、一定の寿命と一致する一定の値または値が含まれています。どちらの場合も、このアルゴリズムは、アドレスごとのライフタイムごとに1回の順序で更新されます。これは、Stateful DHCPV6を使用して必要なリフレッシュの数に似ています。
* Because refreshes occur at least once per address lifetime, the network administrator can control the address refresh frequency by appropriately setting the Valid Lifetime in the PIO.
* リフレッシュはアドレスの寿命ごとに少なくとも1回発生するため、ネットワーク管理者は、PIOで有効な寿命を適切に設定することにより、アドレスの更新周波数を制御できます。
A statically assigned address has an infinite Valid Lifetime that is not affected by RAs. Therefore, whenever the client registers or refreshes a statically assigned address, the next refresh is scheduled for StaticAddrRegRefreshInterval seconds in the future. The default value of StaticAddrRegRefreshInterval is 4 hours. This ensures static addresses are still refreshed periodically, but refreshes for static addresses do not cause excessive multicast traffic. The StaticAddrRegRefreshInterval interval SHOULD be configurable.
静的に割り当てられたアドレスには、RASの影響を受けない無限の有効な寿命があります。したがって、クライアントが静的に割り当てられたアドレスを登録または更新するたびに、次の更新は将来のstaticAddrregrefreshintervalの秒にスケジュールされます。StaticAddrregrefreshintervalのデフォルト値は4時間です。これにより、静的アドレスが定期的に更新されるようになりますが、静的アドレスのリフレッシュは過度のマルチキャストトラフィックを引き起こしません。staticAddrregrefreshinterval間の間隔は構成可能である必要があります。
When a refresh is performed, the client MAY refresh all addresses assigned to the interface that are scheduled to be refreshed within the next AddrRegRefreshCoalesce seconds. The value of AddrRegRefreshCoalesce is implementation dependent, and a suggested default is 60 seconds.
更新が実行されると、クライアントは、次のaddRregrefreshcoalesce秒以内に更新される予定のインターフェイスに割り当てられたすべてのアドレスを更新できます。AddRregrefreshcoalesceの値は実装に依存しており、提案されたデフォルトは60秒です。
Registration refresh packets MUST be retransmitted using the same logic as used for initial registrations (see Section 4.5).
登録更新パケットは、初期登録に使用されるのと同じロジックを使用して再送信する必要があります（セクション4.5を参照）。
The client MUST generate a new transaction ID when refreshing the registration.
クライアントは、登録を更新するときに新しいトランザクションIDを生成する必要があります。
When a Client-Identifier-to-IPv6-address binding expires, the server MUST remove it and consider the address as available for use.
クライアントIdentifier-to-IPV6-Addressバインディングバインディングの有効期限が切れる場合、サーバーはそれを削除し、住所を使用できると考える必要があります。
The client MAY choose to notify the server when an address is no longer being used (e.g., if the client is disconnecting from the network, the address lifetime expired, or the address is being removed from the interface). To indicate that the address is not being used anymore, the client MUST set the preferred-lifetime and valid-lifetime fields of the IA Address option in the ADDR-REG-INFORM message to zero. If the server receives a message with a valid-lifetime of zero, it MUST act as if the address has expired.
クライアントは、アドレスが使用されなくなったときにサーバーに通知することを選択できます（たとえば、クライアントがネットワークから切断されている場合、アドレスの寿命が切れる場合、またはアドレスがインターフェイスから削除されています）。アドレスがもはや使用されていないことを示すには、クライアントは、addr-reg-informメッセージにzeroにaddr-reg-informメッセージで、IAアドレスオプションの優先標準時および有効なリフェティタイムフィールドを設定する必要があります。サーバーが有効なゼロのメッセージを受信した場合、アドレスの有効期限が切れているかのように動作する必要があります。
DHCP clients SHOULD allow the administrator to disable sending ADDR-REG-INFORM messages. Sending the messages SHOULD be enabled by default.
DHCPクライアントは、管理者がAddr-Reg-Informメッセージの送信を無効にすることを許可する必要があります。メッセージの送信はデフォルトで有効にする必要があります。
An attacker may attempt to register a large number of addresses in quick succession in order to overwhelm the address registration server and/or fill up log files. Similar attack vectors exist today, e.g., an attacker can DoS the server with messages containing spoofed DHCP Unique Identifiers (DUIDs) [RFC8415].
攻撃者は、アドレス登録サーバーを圧倒したり、ログファイルを埋めるために、多数のアドレスを迅速に連続して登録しようとする場合があります。同様の攻撃ベクトルが今日存在します。たとえば、攻撃者は、スプーフィングされたDHCP一意の識別子（DUIDS）を含むメッセージを使用してサーバーをDOSすることができます[RFC8415]。
If a network is using First-Come, First-Served Source Address Validation Improvement (FCFS SAVI) [RFC6620], then the DHCPv6 server can trust that the ADDR-REG-INFORM message was sent by the legitimate holder of the address. This prevents a client from registering an address configured on another client.
ネットワークがファーストカムの最初のソースアドレス検証改善（FCFS SAVI）[RFC6620]を使用している場合、DHCPV6サーバーは、アドレスの正当な所有者によってAddR-Reg-Informメッセージが送信されたことを信頼できます。これにより、クライアントが別のクライアントで構成されたアドレスを登録することができなくなります。
One of the use cases for the mechanism described in this document is to identify sources of malicious traffic after the fact. Note, however, that as the device itself is responsible for informing the DHCPv6 server that it is using an address, a malicious or compromised device can simply choose to not send the ADDR-REG-INFORM message. This is an informational, optional mechanism and is designed to aid in troubleshooting and forensics. On its own, it is not intended to be a strong security access mechanism. In particular, the ADDR-REG-INFORM message MUST NOT be used for authentication and authorization purposes, because in addition to the reasons above, the packets containing the message may be dropped.
このドキュメントで説明されているメカニズムのユースケースの1つは、事実の後に悪意のあるトラフィックの原因を特定することです。ただし、デバイス自体がアドレスを使用していることをDHCPV6サーバーに通知する責任があるため、悪意のあるデバイスまたは侵害されたデバイスは、AddR-Reg-Informメッセージを送信しないことを選択できます。これは情報提供のオプションのメカニズムであり、トラブルシューティングとフォレンジックを支援するように設計されています。それだけでは、強力なセキュリティアクセスメカニズムになることを意図したものではありません。特に、上記の理由に加えて、メッセージを含むパケットが削除される可能性があるため、AddR-Reg-Informメッセージを認証と承認の目的に使用する必要はありません。
If the network doesn't have Multicast Listener Discovery (MLD) snooping enabled, then IPv6 link-local multicast traffic is effectively transmitted as broadcast. In such networks, an on-link attacker listening to DHCPv6 messages might obtain information about IPv6 addresses assigned to the client. As ADDR-REG-INFORM messages contain unique identifiers such as the client's DUID, the attacker may be able to track addresses being registered and map them to the same client, even if the client uses randomized MAC addresses. This privacy consideration is not specific to the proposed mechanism. Section 4.3 of [RFC7844] discusses using the DUID for device tracking in DHCPv6 environments and provides mitigation recommendations.
ネットワークにマルチキャストリスナーディスカバリー（MLD）スヌーピングが有効になっていない場合、IPv6 Link-Local Multicastトラフィックは放送として効果的に送信されます。このようなネットワークでは、DHCPV6メッセージを聞くリンク攻撃者がクライアントに割り当てられたIPv6アドレスに関する情報を取得する場合があります。AddR-Reg-Informメッセージには、クライアントのDUIDなどの一意の識別子が含まれているため、攻撃者は、クライアントがランダム化されたMACアドレスを使用していても、登録されているアドレスを追跡して同じクライアントにマッピングできる場合があります。このプライバシーの考慮は、提案されたメカニズムに固有のものではありません。[RFC7844]のセクション4.3は、DHCPV6環境でのデバイス追跡にDUIDを使用して、緩和の推奨事項を提供します。
In general, hiding information about the specific IPv6 address from on-link observers should not be considered a security measure, as such information is usually disclosed via Duplicate Address Detection [RFC4862] to all nodes anyway, if MLD snooping is not enabled.
一般に、MLDスヌーピングが有効になっていない場合、とにかくすべてのノードにそのような情報が開示されるため、そのような情報は通常、そのような情報がすべてのノードに開示されるため、リンクオンオブザーバーからの特定のIPv6アドレスに関する情報を隠すことはセキュリティ尺度と見なされるべきではありません。
If MLD snooping is enabled, an attacker might be able to join the All_DHCP_Relay_Agents_and_Servers multicast address (ff02::1:2) group to listen for address registration messages. However, the same result can be achieved by joining the All Routers Address (ff02::2) group and listen to gratuitous neighbor advertisement messages [RFC9131]. It should be noted that this particular scenario shares the fate with DHCPv6 address assignment: if an attacker can join the All_DHCP_Relay_Agents_and_Servers multicast group, they would be able to monitor all DHCPv6 messages sent from the client to DHCPv6 servers and relays and therefore obtain the information about addresses being assigned via DHCPv6. Layer 2 isolation allows mitigating this threat by blocking on-link peer-to-peer communication between nodes.
MLDスヌーピングが有効になっている場合、攻撃者はALL_DHCP_RELAY_AGENTS_AND_SERVERS MULTICASTアドレス（FF02 :: 1：2）グループに参加してアドレス登録メッセージを聞くことができる場合があります。ただし、すべてのルーターアドレス（FF02 :: 2）グループに参加して、無償の近隣広告メッセージ[RFC9131]を聴くことで、同じ結果を達成できます。この特定のシナリオは、DHCPV6アドレスの割り当てと運命を共有していることに注意してください。攻撃者がALL_DHCP_RELAY_AGENTS_AND_SERVERS MULTICASTグループに参加できる場合、クライアントからDHCPV6セルバーとリレーとリレーのすべてのDHCPV6メッセージを監視し、情報を入手できます。DHCPV6を介して割り当てられているアドレス。レイヤー2の分離により、ノード間のオンリンクピアツーピア通信をブロックすることにより、この脅威を軽減できます。
This document introduces the following entities, which have been allocated in the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry group defined at <http://www.iana.org/assignments/ dhcpv6-parameters>. These include:
このドキュメントでは、次のエンティティを紹介します。これらのエンティティは、<http://www.iana.org/assignments/ dhcpv6-parameters>で定義されている「IPv6（dhcpv6）の動的ホスト構成プロトコル」レジストリグループに割り当てられています。これらには以下が含まれます：
* One new DHCPv6 option, described in Section 4.1, which has been allocated in the "Option Codes" registry:
* セクション4.1で説明されている1つの新しいDHCPV6オプション。「オプションコード」レジストリで割り当てられています。
Value:
値：
148
148
Description:
説明：
OPTION_ADDR_REG_ENABLE
option_addr_reg_enable
Client ORO:
クライアントORO：
Yes
はい
Singleton Option:
シングルトンオプション：
Yes
はい
Reference:
参照：
RFC 9686
RFC 9686
* Two new DHCPv6 messages, which have been allocated in the "Message Types" registry (for more information, see Sections 4.2 and 4.3, respectively, for each DHCPv6 message):
* 「メッセージタイプ」レジストリに割り当てられている2つの新しいDHCPV6メッセージ（詳細については、それぞれDHCPV6メッセージごとにセクション4.2と4.3を参照）を参照してください）：
Value:
値：
36
36
Description:
説明：
ADDR-REG-INFORM
addr-reg-inform
Reference:
参照：
RFC 9686
RFC 9686
Value:
値：
37
37
Description:
説明：
ADDR-REG-REPLY
Addr-Reg-Reply
Reference:
参照：
RFC 9686
RFC 9686
[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>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
DOI 10.17487/RFC4007, March 2005,
<https://www.rfc-editor.org/info/rfc4007>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>.
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
Option", RFC 4704, DOI 10.17487/RFC4704, October 2006,
<https://www.rfc-editor.org/info/rfc4704>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer
Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939,
May 2013, <https://www.rfc-editor.org/info/rfc6939>.
[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>.
[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>.
[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>.
[RFC9131] Linkova, J., "Gratuitous Neighbor Discovery: Creating
Neighbor Cache Entries on First-Hop Routers", RFC 9131,
DOI 10.17487/RFC9131, October 2021,
<https://www.rfc-editor.org/info/rfc9131>.
[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>.
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses",
RFC 6620, DOI 10.17487/RFC6620, May 2012,
<https://www.rfc-editor.org/info/rfc6620>.
Many thanks to Bernie Volz for the significant review and feedback, as well as Hermin Anggawijaya, Carlos Jesus Bernardos, Brian Carpenter, Stuart Cheshire, Roman Danyliw, Alan DeKok, James Guichard, James Guichard, Erik Kline, Mallory Knodel, Murray Kucherawy, David Lamparter, Ted Lemon, Eric Levy-Abegnoli, Aditi Patange, Jim Reid, Michael Richardson, Patrick Rohr, John Scudder, Mark Smith, Gunter Van de Velde, Eric Vyncke, Timothy Winters, and Peter Yee for their feedback, comments, and guidance. We apologize if we inadvertently forgot to acknowledge anyone's contributions.
重要なレビューとフィードバック、ハーミンアンガウィジャヤ、カルロスジーザスバーナルドス、ブライアンカーペンター、スチュアートチェシャー、スチュアートチェシャー、ローマンダニリウ、アランデコック、ジェームズギチャード、ジェームズギチャード、エリッククライン、マロリーノードル、マレークエラウィー、デイビッド、デイビッドランパター、テッド・レモン、エリック・レヴィー・アベグノリ、アディティ・パターンジ、ジム・リード、マイケル・リチャードソン、パトリック・ローア、ジョン・スカダー、マーク・スミス、ガンター・ヴァン・デ・ヴェルデ、エリック・ヴィンケ、タイムシー・ウィンターズ、ピーター・イーのフィードバック、コメント、指導のためにピーター・イー。誰の貢献を認めるのを不注意に忘れてしまったことをお詫びします。
Gang Chen
China Mobile
53A, Xibianmennei Ave.
Xuanwu District
Beijing
China
Email: phdgang@gmail.com
Warren Kumari
Google, LLC
Email: warren@kumari.net
Suresh Krishnan
Cisco Systems, Inc.
Email: suresh.krishnan@gmail.com
Rajiv Asati
Independent
Email: rajiv.asati@gmail.com
Lorenzo Colitti
Google, LLC
Shibuya 3-21-3,
Japan
Email: lorenzo@google.com
Jen Linkova
Google, LLC
1 Darling Island Rd
Pyrmont 2009
Australia
Email: furry13@gmail.com
Sheng Jiang
Beijing University of Posts and Telecommunications
No. 10 Xitucheng Road
Beijing
Haidian District, 100083
China
Email: shengjiang@bupt.edu.cn