Internet Engineering Task Force (IETF) D. Migault
Request for Comments: 9527 Ericsson
Category: Standards Track R. Weber
ISSN: 2070-1721 Akamai
T. Mrugalski
ISC
January 2024
This document defines DHCPv6 options so that a Homenet Naming Authority (HNA) can automatically set the appropriate configuration and outsource the authoritative naming service for the home network. In most cases, the outsourcing mechanism is transparent for the end user.
このドキュメントでは、DHCPV6オプションを定義しているため、Homenet Naming Authority（HNA）が適切な構成を自動的に設定し、ホームネットワークの権威ある命名サービスを外部委託できるようにします。ほとんどの場合、アウトソーシングメカニズムはエンドユーザーにとって透明です。
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/rfc9527.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9527で取得できます。
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. Terminology
3. Procedure Overview
4. DHCPv6 Options
4.1. Registered Homenet Domain Option
4.2. Forward Distribution Manager Option
4.3. Reverse Distribution Manager Server Option
4.4. Supported Transport
5. DHCPv6 Behavior
5.1. DHCPv6 Server Behavior
5.2. DHCPv6 Client Behavior
5.3. DHCPv6 Relay Agent Behavior
6. IANA Considerations
6.1. DHCPv6 Option Codes
6.2. Supported Transport Parameter
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Scenarios and Impact on the End User
A.1. Base Scenario
A.2. Third-Party Registered Homenet Domain
A.3. Third-Party DNS Infrastructure
A.4. Multiple ISPs
Acknowledgments
Contributors
Authors' Addresses
[RFC9526] specifies how an entity designated as the Homenet Naming Authority (HNA) outsources a Public Homenet Zone to a DNS Outsourcing Infrastructure (DOI).
[RFC9526]は、Homenet Naming Authority（HNA）として指定されたエンティティが、DNSアウトソーシングインフラストラクチャ（DOI）に公開ホームネットゾーンをアウトソーシングする方法を指定します。
This document describes how a network can provision the HNA with a specific DOI. This could be particularly useful for a DOI partly managed by an ISP or to make home networks resilient to HNA replacement. The ISP delegates an IP prefix and the associated reverse zone to the home network. The ISP is thus aware of the owner of that IP prefix and, as such, becomes a natural candidate for hosting the Homenet Reverse Zone -- that is, the Reverse Distribution Manager (RDM) and potentially the Reverse Public Authoritative Servers.
このドキュメントでは、ネットワークがHNAに特定のDOIをプロビジョニングする方法について説明します。これは、ISPによって部分的に管理されているDOIや、HNAの交換に対してホームネットワークを回復力のあるものにするために特に役立ちます。ISPは、IPプレフィックスと関連するリバースゾーンをホームネットワークに委任します。したがって、ISPはそのIPプレフィックスの所有者を認識しており、そのため、Homenet Reverse Zone、つまりリバースディストリビューションマネージャー（RDM）をホストするための自然な候補になり、潜在的には逆の公共権限サーバーになります。
In addition, ISPs often identify the line of the home network with a name. Such name is used for their internal network management operations and is not a name the home network owner has registered to. ISPs may leverage such infrastructure and provide the home network with a specific domain name designated per a Registered Homenet Domain [RFC9526]. Similarly to the reverse zone, ISPs are aware of who owns that domain name and may become a natural candidate for hosting the Homenet Zone -- that is, the Distribution Manager (DM) and the Public Authoritative Servers.
さらに、ISPはしばしば名前のホームネットワークの行を識別します。このような名前は、内部ネットワーク管理操作に使用されており、ホームネットワークの所有者が登録した名前ではありません。ISPは、このようなインフラストラクチャを活用し、登録されたホメネットドメイン[RFC9526]に従って指定された特定のドメイン名をホームネットワークに提供する場合があります。リバースゾーンと同様に、ISPは誰がそのドメイン名を所有しているかを認識しており、Homenetゾーン、つまり配布マネージャー（DM）と公共の権威あるサーバーをホストするための自然な候補になる可能性があります。
This document describes DHCPv6 options that enable an ISP to provide the necessary parameters to the HNA to proceed. More specifically, the ISP provides the Registered Homenet Domain and the necessary information on the DM and the RDM so the HNA can manage and upload the Public Homenet Zone and the Reverse Public Homenet Zone as described in [RFC9526].
このドキュメントでは、ISPがHNAに必要なパラメーターを進めることができるDHCPV6オプションについて説明します。より具体的には、ISPは、[RFC9526]に記載されているように、HNAがパブリックホームネットゾーンと逆パブリックホメネットゾーンを管理およびアップロードできるように、登録されたホメネットドメインとDMとRDMに関する必要な情報を提供します。
The use of DHCPv6 options may make the configuration completely transparent to the end user and provides a similar level of trust as the one used to provide the IP prefix, when provisioned via DHCP.
DHCPV6オプションを使用すると、構成はエンドユーザーに対して完全に透過的になり、DHCPを介してプロビジョニングされた場合、IPプレフィックスを提供するために使用されるものと同様のレベルの信頼を提供する場合があります。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
The reader should be familiar with [RFC9526].
読者は[RFC9526]に精通している必要があります。
This section illustrates how an HNA receives the necessary information via DHCPv6 options to outsource its authoritative naming service to the DOI. For the sake of simplicity, and similarly to [RFC9526], this section assumes that the HNA and the home network DHCPv6 client are colocated on the Customer Premises Equipment (CPE) router [RFC7368]. Also, note that this is not mandatory, and the DHCPv6 client may remotely instruct the HNA with a protocol that will be standardized in the future. In addition, this section assumes that the responsible entity for the DHCPv6 server is provisioned with the DM and RDM information, which is associated with the requested Registered Homenet Domain. This means a Registered Homenet Domain can be associated with the DHCPv6 client.
このセクションでは、HNAがDHCPV6オプションを介して必要な情報を受信して、権威ある命名サービスをDOIに外注する方法を示しています。単純化のために、そして[RFC9526]と同様に、このセクションでは、HNAとホームネットワークDHCPV6クライアントが顧客施設機器（CPE）ルーター[RFC7368]にコロンケートされていると想定しています。また、これは必須ではなく、DHCPV6クライアントは将来標準化されるプロトコルをHNAにリモートで指示することができることに注意してください。さらに、このセクションでは、DHCPV6サーバーの責任あるエンティティが、要求された登録済みホメネットドメインに関連付けられているDMおよびRDM情報でプロビジョニングされていると想定しています。これは、登録されたHomenetドメインをDHCPV6クライアントに関連付けることができることを意味します。
This scenario is believed to be the most popular scenario. This document does not ignore scenarios where the DHCPv6 server does not have privileged relations with the DM or RDM. These cases are discussed in Appendix A. Such scenarios do not necessarily require configuration for the end user and can also be zero configuration.
このシナリオは、最も人気のあるシナリオであると考えられています。このドキュメントでは、DHCPV6サーバーがDMまたはRDMとの特権的な関係がないシナリオを無視しません。これらのケースについては、付録Aで説明します。このようなシナリオは、必ずしもエンドユーザーの構成を必要とするわけではなく、構成もゼロにすることもできます。
The scenario considered in this section is as follows:
このセクションで検討されているシナリオは次のとおりです。
1. The HNA is willing to outsource the Public Homenet Zone or Homenet Reverse Zone. The DHCPv6 client is configured to include in its Option Request Option (ORO) the Registered Homenet Domain Option (OPTION_REGISTERED_DOMAIN), the Forward Distribution Manager Option (OPTION_FORWARD_DIST_MANAGER), and the Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER) option codes.
1. HNAは、パブリックホームネットゾーンまたはホメネットリバースゾーンを外部委託することをいとわない。DHCPV6クライアントは、オプションリクエストオプション（ORO）に登録済みHomenetドメインオプション（OPTION_REGISTERED_DOMAIN）、フォワード配信マネージャーオプション（Option_Forward_Dist_Manager）、およびReverse Manager Options（Option_Reverse_Dist_Manager）オプションコードを含めるように構成されています。
2. The DHCPv6 server responds to the DHCPv6 client with the requested DHCPv6 options based on the identified homenet. The DHCPv6 client passes the information to the HNA.
2. DHCPV6サーバーは、特定されたホメネットに基づいて要求されたDHCPV6オプションを使用してDHCPV6クライアントに応答します。DHCPV6クライアントは、情報をHNAに渡します。
3. The HNA is authenticated (see "Securing the Control Channel" (Section 6.6) of [RFC9526]) by the DM and the RDM. The HNA builds the Homenet Zone (or the Homenet Reverse Zone) and proceeds as described in [RFC9526]. The DHCPv6 options provide the necessary non-optional parameters described in Appendix B of [RFC9526]. The HNA may complement the configurations with additional parameters via means not yet defined. Appendix B of [RFC9526] describes such parameters that may take some specific non-default value.
3. HNAは、DMおよびRDMによって認証されます（[RFC9526]の[RFC9526]の「セクション6.6）を参照）。HNAは、Homenet Zone（またはHomenet Reverse Zone）を構築し、[RFC9526]に記載されているように進行します。DHCPV6オプションは、[RFC9526]の付録Bに記載されている必要な非感受性パラメーターを提供します。HNAは、まだ定義されていない手段を介して追加のパラメーターで構成を補完する場合があります。[RFC9526]の付録Bは、特定の非デフォルト値をとる可能性のあるこのようなパラメーターについて説明しています。
This section details the payload of the DHCPv6 options following the guidelines of [RFC7227].
このセクションでは、[RFC7227]のガイドラインに従って、DHCPV6オプションのペイロードを詳しく説明しています。
The Registered Domain Option (OPTION_REGISTERED_DOMAIN) indicates the fully qualified domain name (FQDN) associated with the home network.
登録済みドメインオプション（option_registered_domain）は、ホームネットワークに関連付けられている完全資格のドメイン名（FQDN）を示します。
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_REGISTERED_DOMAIN | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Registered Homenet Domain /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Registered Domain Option
図1：登録ドメインオプション
option-code (16 bits):
オプションコード（16ビット）：
OPTION_REGISTERED_DOMAIN; the option code for the Registered Homenet Domain (145).
option_registered_domain;登録されたHomenetドメインのオプションコード（145）。
option-len (16 bits):
Option-Len（16ビット）：
Length in octets of the Registered Homenet Domain field as described in [RFC8415].
[RFC8415]に記載されているように、登録されたホメネットドメインフィールドのオクテットの長さ。
Registered Homenet Domain (variable):
登録済みHomenetドメイン（変数）：
The FQDN registered for the homenet encoded as described in Section 10 of [RFC8415].
FQDNは、[RFC8415]のセクション10で説明されているようにエンコードされたホメネットに登録されています。
The Forward Distribution Manager Option (OPTION_FORWARD_DIST_MANAGER) provides the HNA with the FQDN of the DM as well as the transport protocols for the communication between the HNA and the DM. As opposed to IP addresses, the FQDN requires a DNS resolution before establishing the communication between the HNA and the DM. However, the use of an FQDN provides multiple advantages over IP addresses. Firstly, it makes the DHCPv6 option easier to parse and smaller, especially when IPv4 and IPv6 addresses are expected to be provided. Then, the FQDN can reasonably be seen as a more stable identifier than IP addresses as well as a pointer to additional information that may be useful, in the future, to establish the communication between the HNA and the DM.
Forward Distribution Managerオプション（Option_Forward_Dist_Manager）は、HNAにDMのFQDNと、HNAとDM間の通信のためのトランスポートプロトコルを提供します。IPアドレスとは対照的に、FQDNはHNAとDMの間の通信を確立する前にDNS解像度を必要とします。ただし、FQDNの使用は、IPアドレスよりも複数の利点を提供します。まず、特にIPv4およびIPv6アドレスが提供されると予想される場合、DHCPV6オプションが解析や小さくなりやすくなります。次に、FQDNは、IPアドレスよりも安定した識別子と同様に、HNAとDMの間の通信を確立するために有用な追加情報へのポインターと同様に合理的に見られることがあります。
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_FORWARD_DIST_MANAGER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Transport | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Distribution Manager FQDN /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Forward Distribution Manager Option
図2：フォワード配信マネージャーオプション
option-code (16 bits):
オプションコード（16ビット）：
OPTION_FORWARD_DIST_MANAGER; the option code for the Forward Distribution Manager Option (146).
option_forward_dist_manager;Forward Distribution Managerオプションのオプションコード（146）。
option-len (16 bits):
Option-Len（16ビット）：
Length in octets of the enclosed data as described in [RFC8415].
[RFC8415]で説明されているように、囲まれたデータのオクテットの長さ。
Supported Transport (16 bits):
サポートされている輸送（16ビット）：
Defines the Supported Transport by the DM (see Section 4.4). Each bit represents a supported transport, and a DM MAY indicate the support of multiple modes. The bit for DNS over mutually authenticated TLS (DomTLS) MUST be set.
DMによるサポートされている輸送を定義します（セクション4.4を参照）。各ビットはサポートされたトランスポートを表し、DMは複数のモードのサポートを示す場合があります。相互に認証されたTLS（DOMTL）上のDNSのビットを設定する必要があります。
Distribution Manager FQDN (variable):
配布マネージャーFQDN（変数）：
The FQDN of the DM encoded as described in Section 10 of [RFC8415].
[RFC8415]のセクション10で説明されているように、DMのFQDN。
It is worth noting that the DHCPv6 option specifies the Supported Transport without specifying any explicit port. Unless the HNA and the DM have agreed on using a specific port -- for example, by configuration, or any out-of-band mechanism -- the default port is used and must be specified. The specification of such default port may be defined in the specification of the designated Supported Transport or in any other document. In the case of DomTLS, the default port value is 853 per DNS over TLS [RFC7858] and DNS Zone Transfer over TLS [RFC9103].
DHCPV6オプションが、明示的なポートを指定せずにサポートされている輸送を指定することは注目に値します。HNAとDMが特定のポートを使用することに合意していない限り、たとえば、構成、または帯域外のメカニズムにより、デフォルトのポートを使用して指定する必要があります。このようなデフォルトポートの仕様は、指定されたサポートされている輸送の仕様またはその他のドキュメントで定義できます。DOMTLSの場合、デフォルトのポート値は、TLS [RFC7858]およびTLS [RFC9103]を介したDNSゾーン転送でDNSあたり853です。
The need to associate the port value to each Supported Transport in the DHCPv6 option has been balanced with the difficulty of handling a list of tuples (transport, port) and the possibility of using a dedicated IP address for the DM in case the default port is already in use.
DHCPV6オプションでサポートされている各トランスポートにポート値を関連付ける必要性は、タプル（輸送、ポート）のリストを処理することの難しさと、デフォルトのポートがある場合にDMに専用のIPアドレスを使用する可能性とバランスが取れています。すでに使用されています。
The Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER) provides the HNA with the FQDN of the DM as well as the transport protocols for the communication between the HNA and the DM.
Reverse Distribution Managerオプション（Option_Reverse_Dist_Manager）は、HNAにDMのFQDNと、HNAとDM間の通信のためのトランスポートプロトコルを提供します。
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_REVERSE_DIST_MANAGER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Transport | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Reverse Distribution Manager FQDN /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Reverse Distribution Manager Option
図3：逆配布マネージャーオプション
option-code (16 bits):
オプションコード（16ビット）：
OPTION_REVERSE_DIST_MANAGER; the option code for the Reverse Distribution Manager Option (147).
option_reverse_dist_manager;逆配布マネージャーオプションのオプションコード（147）。
option-len (16 bits):
Option-Len（16ビット）：
Length in octets of the option-data field as described in [RFC8415].
[RFC8415]に記載されているように、オプションデータフィールドのオクテットの長さ。
Supported Transport (16 bits):
サポートされている輸送（16ビット）：
Defines the Supported Transport by the RDM (see Section 4.4). Each bit represents a supported transport, and an RDM MAY indicate the support of multiple modes. The bit for DomTLS [RFC7858] MUST be set.
RDMによるサポートされている輸送を定義します（セクション4.4を参照）。各ビットはサポートされたトランスポートを表し、RDMは複数のモードのサポートを示す場合があります。domtls [rfc7858]のビットを設定する必要があります。
Reverse Distribution Manager FQDN (variable):
リバースディストリビューションマネージャーFQDN（変数）：
The FQDN of the RDM encoded as described in Section 10 of [RFC8415].
[RFC8415]のセクション10で説明されているように、RDMのFQDN。
For the port number associated to the Supported Transport, the same considerations as described in Section 4.2 apply.
サポートされている輸送に関連付けられたポート番号の場合、セクション4.2の説明と同じ考慮事項が適用されます。
The Supported Transport field of the DHCPv6 option indicates the Supported Transport protocols. Each bit represents a specific transport mechanism. A bit set to 1 indicates the associated transport protocol is supported. The corresponding bits are assigned as described in Table 2.
DHCPV6オプションのサポートされている輸送フィールドは、サポートされている輸送プロトコルを示します。各ビットは、特定の輸送メカニズムを表します。1に設定されていると、関連する輸送プロトコルがサポートされていることを示します。対応するビットは、表2に記載されているように割り当てられます。
DNS over mutually authenticated TLS (DomTLS):
相互に認証されたTLS（DOMTL）を超えるDNS：
Indicates the support of DNS over TLS [RFC7858] and DNS Zone Transfer over TLS [RFC9103] as described in [RFC9526].
[RFC9526]に記載されているように、TLS [RFC7858]およびTLS [RFC9103]を介したDNSゾーン転送に対するDNSのサポートを示します。
As an example, the Supported Transport field expressing support for DomTLS looks as follows and has a numeric value of 0x0001:
例として、DOMTLのサポートを表現するサポートされている輸送フィールドは次のように見え、数値は0x0001です。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| must be zero |1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 18.3 of [RFC8415] governs server operation regarding option assignment. As a convenience to the reader, we mention here that the server will send option foo only if configured with specific values for foo and if the client requested it. In particular, when configured, the DHCPv6 server sends the Registered Homenet Domain Option, Distribution Manager Option, and Reverse Distribution Manager Option when requested by the DHCPv6 client by including necessary option codes in its ORO.
[RFC8415]のセクション18.3は、オプションの割り当てに関するサーバー操作を規定しています。読者にとって便利であるため、ここでは、FOOの特定の値で構成された場合にのみ、サーバーがオプションFOOを送信すること、クライアントがそれを要求した場合にのみここで言及します。特に、構成された場合、DHCPV6サーバーは、DHCPV6クライアントがOROに必要なオプションコードを含めることにより、DHCPV6クライアントが要求したときに、登録されたHomenetドメインオプション、配布マネージャーオプション、および逆配布マネージャーオプションを送信します。
The DHCPv6 client includes the Registered Homenet Domain Option, Distribution Manager Option, and Reverse Distribution Manager Option in an ORO as specified in Sections 18.2 and 21.7 of [RFC8415].
DHCPV6クライアントには、[RFC8415]のセクション18.2および21.7で指定されているように、OROの登録済みHomenetドメインオプション、配布マネージャーオプション、および逆配布マネージャーオプションが含まれています。
Upon receiving a DHCPv6 option, as described in this document, in the Reply message, the HNA SHOULD proceed as described in [RFC9526].
このドキュメントで説明されているように、DHCPV6オプションを受信すると、返信メッセージで、[RFC9526]で説明されているようにHNAが進行する必要があります。
There are no additional requirements for the DHCPv6 Relay agents.
DHCPV6リレーエージェントの追加要件はありません。
IANA has assigned the following new DHCPv6 Option Codes in the "Option Codes" registry maintained at <https://www.iana.org/assignments/dhcpv6-parameters>.
IANAは、<https://www.iana.org/assignments/dhcpv6-parameters>に維持されている「オプションコード」レジストリに次の新しいDHCPV6オプションコードを割り当てました。
+=====+=============================+======+===========+===========+
|Value| Description |Client| Singleton | Reference |
| | |ORO | Option | |
+=====+=============================+======+===========+===========+
|145 | OPTION_REGISTERED_DOMAIN |Yes | No | RFC 9527, |
| | | | | Section |
| | | | | 4.1 |
+-----+-----------------------------+------+-----------+-----------+
|146 | OPTION_FORWARD_DIST_MANAGER |Yes | Yes | RFC 9527, |
| | | | | Section |
| | | | | 4.2 |
+-----+-----------------------------+------+-----------+-----------+
|147 | OPTION_REVERSE_DIST_MANAGER |Yes | Yes | RFC 9527, |
| | | | | Section |
| | | | | 4.3 |
+-----+-----------------------------+------+-----------+-----------+
Table 1: Option Codes Registry
表1：オプションコードレジストリ
IANA has created and maintains a new registry called "Supported Transport" under the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry at <https://www.iana.org/assignments/ dhcpv6-parameters>. This registry contains Supported Transport parameters in the Distributed Manager Option (OPTION_FORWARD_DIST_MANAGER) or the Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER). The different parameters are defined in Table 2 (Section 6.2).
IANAは、<https://www.iana.org/assignments/ dhcpv6-parameters>の「IPv6（dhcpv6）の動的ホスト構成プロトコル」レジストリの下で「サポートされたトランスポート」と呼ばれる新しいレジストリを作成および維持しています。このレジストリには、分散マネージャーオプション（option_forward_dist_manager）または逆配布マネージャーオプション（option_reverse_dist_manager）のサポートされているトランスポートパラメーターが含まれています。さまざまなパラメーターを表2（セクション6.2）に定義します。
The Supported Transport field of the DHCPv6 option is a two-octet field that indicates the Supported Transport protocols. Each bit represents a specific transport mechanism.
DHCPV6オプションのサポートされている輸送フィールドは、サポートされている輸送プロトコルを示す2オクタートフィールドです。各ビットは、特定の輸送メカニズムを表します。
New entries MUST specify the bit position, the transport protocol description, a mnemonic, and a reference as shown in Table 2.
新しいエントリは、表2に示すように、ビット位置、トランスポートプロトコルの説明、ニーモニック、および参照を指定する必要があります。
Changes to the format or policies of the registry are managed by the IETF via the IESG.
レジストリの形式またはポリシーの変更は、IESGを介してIETFによって管理されます。
Future code points are assigned under RFC Required per [RFC8126]. The initial registry is as specified in Table 2 below.
将来のコードポイントは、[RFC8126]ごとに必要なRFCに割り当てられます。初期レジストリは、以下の表2に指定されています。
+======================+====================+==========+===========+
| Bit Position (least | Transport Protocol | Mnemonic | Reference |
| to most significant) | Description | | |
+======================+====================+==========+===========+
| 0 | DNS over mutually | DomTLS | RFC 9527 |
| | authenticated TLS | | |
+----------------------+--------------------+----------+-----------+
| 1-15 | Unassigned | | |
+----------------------+--------------------+----------+-----------+
Table 2: Supported Transport Registry
表2：サポートされている輸送レジストリ
The security considerations in [RFC8415] are to be considered. The trust associated with the information carried by the DHCPv6 options described in this document is similar to the one associated with the IP prefix, when configured via DHCPv6.
[RFC8415]のセキュリティ上の考慮事項を考慮する必要があります。このドキュメントで説明されているDHCPV6オプションによって伝達される情報に関連付けられている信頼は、DHCPV6を介して構成された場合、IPプレフィックスに関連付けられたものと類似しています。
In some cases, the ISP MAY identify the HNA by its wire line (i.e., physically), which may not require relying on TLS to authenticate the HNA. As the use of TLS is mandatory, it is expected that the HNA will be provisioned with a certificate. In some cases, the HNA may use a self-signed certificate.
場合によっては、ISPはそのワイヤライン（つまり、物理的に）でHNAを識別することがあり、HNAを認証するためにTLSに依存する必要はない場合があります。TLSの使用が必須であるため、HNAに証明書がプロビジョニングされることが予想されます。場合によっては、HNAは自己署名証明書を使用する場合があります。
[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>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC9103] Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A.
Mankin, "DNS Zone Transfer over TLS", RFC 9103,
DOI 10.17487/RFC9103, August 2021,
<https://www.rfc-editor.org/info/rfc9103>.
[RFC9526] Migault, D., Weber, R., Richardson, M., and R. Hunter,
"Simple Provisioning of Public Names for Residential
Networks", RFC 9526, DOI 10.17487/RFC9526, January 2024,
<https://www.rfc-editor.org/info/rfc9526>.
[CNAME-PLUS-DNAME]
Surý, O., "CNAME+DNAME Name Redirection", Work in
Progress, Internet-Draft, draft-sury-dnsop-cname-plus-
dname-01, 15 July 2018,
<https://datatracker.ietf.org/doc/html/draft-sury-dnsop-
cname-plus-dname-01>.
[PD-REVERSE]
Andrews, M., "Automated Delegation of IP6.ARPA reverse
zones with Prefix Delegation", Work in Progress, Internet-
Draft, draft-andrews-dnsop-pd-reverse-02, 5 November 2013,
<https://datatracker.ietf.org/doc/html/draft-andrews-
dnsop-pd-reverse-02>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<https://www.rfc-editor.org/info/rfc2181>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<https://www.rfc-editor.org/info/rfc6672>.
[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>.
[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
Weil, "IPv6 Home Networking Architecture Principles",
RFC 7368, DOI 10.17487/RFC7368, October 2014,
<https://www.rfc-editor.org/info/rfc7368>.
This appendix details various scenarios and discusses their impact on the end user. This appendix is not normative and limits the description of a limited scope of scenarios that are assumed to be representative. Many other scenarios may be derived from these.
この付録は、さまざまなシナリオを詳述し、エンドユーザーへの影響について説明します。この付録は規範的ではなく、代表的であると想定されるシナリオの限られた範囲の説明を制限します。他の多くのシナリオは、これらから導き出される場合があります。
The base scenario, as described in Section 3, is one in which an ISP manages the DHCPv6 server, DM, and RDM.
セクション3で説明されているベースシナリオは、ISPがDHCPV6サーバー、DM、およびRDMを管理するものです。
The end user subscribes to the ISP (foo), and at subscription time, it registers foo.example as its Registered Homenet Domain.
エンドユーザーはISP（FOO）にサブスクライブし、サブスクリプション時に登録されたHomenetドメインとしてfoo.exampleを登録します。
In this scenario, the DHCPv6 server, DM, and RDM are managed by the ISP, so the DHCPv6 server and such can provide authentication credentials of the HNA to enable secure authenticated transaction with the DM and the Reverse DM.
このシナリオでは、DHCPV6サーバー、DM、およびRDMがISPによって管理されるため、DHCPV6サーバーなどはHNAの認証資格情報を提供して、DMおよび逆DMで安全な認証トランザクションを可能にします。
The main advantage of this scenario is that the naming architecture is configured automatically and transparently for the end user. The drawbacks are that the end user uses a Registered Homenet Domain managed by the ISP and that it relies on the ISP naming infrastructure.
このシナリオの主な利点は、命名アーキテクチャがエンドユーザー向けに自動的かつ透過的に構成されていることです。欠点は、エンドユーザーがISPによって管理された登録ホメネットドメインを使用し、ISPの命名インフラストラクチャに依存していることです。
This appendix considers the case where the end user wants its home network to use example.com but does not want it to be managed by the ISP (foo) as a Registered Homenet Domain, and the ISP manages the home network and still provides foo.example as a Registered Homenet Domain.
この付録では、エンドユーザーがホームネットワークにExample.comを使用することを望んでいるが、ISP（FOO）によって登録されたHomenetドメインとして管理されることを望まない場合を考慮し、ISPはホームネットワークを管理し、FOOを提供します。登録されたホメネットドメインとしての例。
When the end user buys the domain name example.com, it may request to redirect example.com to foo.example using static redirection with CNAME [RFC1034] [RFC2181], DNAME [RFC6672], or CNAME+DNAME [CNAME-PLUS-DNAME]. The only information the end user needs to know is the domain name assigned by the ISP. Once the redirection has been configured, the HNA may be changed, and the zone can be updated as described in Appendix A.1 without any additional configuration from the end user.
エンドユーザーがドメイン名のexample.comを購入すると、cname [rfc1034] [rfc2181]、dname [rfc6672]、またはcname dname [cname-plus-dnameを使用した静的リダイレクトを使用してfoo.exampleをfoo.exampleにリダイレクトするように要求することができます。]。エンドユーザーが知る必要がある唯一の情報は、ISPによって割り当てられたドメイン名です。リダイレクトが構成されたら、HNAを変更し、エンドユーザーからの追加の構成なしで付録A.1に記載されているようにゾーンを更新できます。
The main advantage of this scenario is that the end user benefits from the zero configuration of the base scenario in Appendix A.1. Then, the end user is able to register an unlimited number of domain names provided by an unlimited number of different third-party providers for its home network. The drawback of this scenario may be that the end user still needs to rely on the ISP naming infrastructure. Note that this may be inconvenient in the case where the DNS servers provided by the ISPs result in high latency.
このシナリオの主な利点は、エンドユーザーが付録A.1のベースシナリオのゼロ構成から利益を得ることです。次に、エンドユーザーは、ホームネットワークのために無制限の数の異なるサードパーティプロバイダーによって提供される無制限の数のドメイン名を登録できます。このシナリオの欠点は、エンドユーザーがISPの命名インフラストラクチャに依存する必要があることです。これは、ISPが提供するDNSサーバーが高いレイテンシをもたらす場合には不便な場合があることに注意してください。
This scenario involves the end user using example.com as a Registered Homenet Domain and not relying on the authoritative servers provided by the ISP.
このシナリオには、Example.comを登録されたHomenetドメインとして使用するエンドユーザーが含まれ、ISPが提供する権威あるサーバーに依存していません。
In this appendix, we limit the outsourcing of the DM and Public Authoritative Server(s) to a third party. The Reverse Public Authoritative Server(s) and the RDM remain managed by the ISP as the IP prefix is managed by the ISP.
この付録では、DMおよびPublic Authoritative Serverのアウトソーシングを第三者に制限します。IPプレフィックスがISPによって管理されているため、逆パブリックの権威あるサーバーとRDMはISPによって管理されたままです。
Outsourcing to a third-party DM can be performed in the following ways:
サードパーティDMへのアウトソーシングは、次の方法で実行できます。
1. Updating the DHCPv6 server information. One can imagine a GUI interface that enables the end user to modify its profile parameters. Again, this configuration update only needs to be performed one time.
1. DHCPV6サーバー情報の更新。エンドユーザーがプロファイルパラメーターを変更できるようにするGUIインターフェイスを想像できます。繰り返しますが、この構成更新は1回実行する必要があります。
2. Uploading the configuration of the DM to the HNA. In some cases, the provider of the CPE router hosting the HNA may be the registrar, and the registrar may provide the CPE router already configured. In other cases, the CPE router may request the end user to log into the registrar to validate the ownership of the Registered Homenet Domain and agree on the necessary credentials to secure the communication between the HNA and the DM. As described in [RFC9526], such settings could be performed in an almost automatic way as to limit the necessary interactions with the end user.
2. DMの構成をHNAにアップロードします。場合によっては、HNAをホストするCPEルーターのプロバイダーがレジストラである可能性があり、レジストラはすでに構成されているCPEルーターを提供する場合があります。他のケースでは、CPEルーターは、登録されたHomenetドメインの所有権を検証するためにエンドユーザーにレジストラにログインするよう要求し、HNAとDM間の通信を確保するために必要な資格情報に同意する場合があります。[RFC9526]で説明されているように、このような設定は、エンドユーザーとの必要な相互作用を制限するように、ほぼ自動的に実行できます。
This scenario involves an HNA connected to multiple ISPs.
このシナリオには、複数のISPに接続されたHNAが含まれます。
Suppose the HNA has configured each of its interfaces independently with each ISP as described in Appendix A.1. Each ISP provides a different Registered Homenet Domain.
付録A.1で説明されているように、HNAが各ISPで各インターフェイスを個別に構成したとします。各ISPは、異なる登録されたホメネットドメインを提供します。
The protocol and DHCPv6 options described in this document are fully compatible with an HNA connected to multiple ISPs with multiple Registered Homenet Domains. However, the HNA should be able to handle different Registered Homenet Domains. This is an implementation issue, which is outside the scope of this document.
このドキュメントで説明されているプロトコルおよびDHCPV6オプションは、複数の登録ホメネットドメインを持つ複数のISPに接続されたHNAと完全に互換性があります。ただし、HNAは異なる登録済みホメネットドメインを処理できるはずです。これは実装の問題であり、このドキュメントの範囲外です。
If an HNA is not able to handle multiple Registered Homenet Domains, the HNA may remain connected to multiple ISPs with a single Registered Homenet Domain. In this case, one entity is chosen to host the Registered Homenet Domain. This entity may be an ISP or a third party. Note that having multiple ISPs can be motivation for bandwidth aggregation or connectivity failover. In the case of connectivity failover, the failover concerns the access network, and a failure of the access network may not impact the core network where the DM and Public Authoritative Primaries are hosted. In that sense, choosing one of the ISPs even in a scenario of multiple ISPs may make sense. However, for the sake of simplicity, this scenario assumes that a third party has been chosen to host the Registered Homenet Domain. Configuration is performed as described in Appendices A.2 and A.3.
HNAが複数の登録済みホメネットドメインを処理できない場合、HNAは単一の登録ホメネットドメインを持つ複数のISPに接続されたままにすることができます。この場合、登録されたHomenetドメインをホストするために1つのエンティティが選択されます。このエンティティは、ISPまたは第三者である場合があります。複数のISPを持つことは、帯域幅の集約または接続性フェールオーバーの動機付けになる可能性があることに注意してください。接続フェールオーバーの場合、フェールオーバーはアクセスネットワークに関係しており、アクセスネットワークの障害は、DMとパブリックの権威あるプライマリーがホストされているコアネットワークに影響を与えない場合があります。その意味で、複数のISPのシナリオでもISPの1つを選択することは理にかなっているかもしれません。ただし、簡単にするために、このシナリオは、登録されたHomenetドメインをホストするために第三者が選択されていることを前提としています。構成は、付録A.2およびA.3で説明されているように実行されます。
With the configuration described in Appendix A.2, the HNA is expected to be able to handle multiple Registered Homenet Domains as the third-party redirect to one of the ISP's servers. With the configuration described in Appendix A.3, DNS zones are hosted and maintained by the third party. A single DNS(SEC) Homenet Zone is built and maintained by the HNA. This latter configuration is likely to match most HNA implementations.
付録A.2で説明されている構成により、HNAは、ISPのサーバーの1つにサードパーティのリダイレクトとして、複数の登録ホメネットドメインを処理できると予想されます。付録A.3で説明されている構成により、DNSゾーンはサードパーティによってホストおよび維持されます。単一のDNS（SEC）HomeNetゾーンがHNAによって構築および維持されます。この後者の構成は、ほとんどのHNA実装と一致する可能性があります。
The protocol and DHCPv6 options described in this document are fully compatible with an HNA connected to multiple ISPs. Whether to configure the HNA or not, and how to configure the HNA, depends on the HNA facilities. Appendices A.1 and A.2 require the HNA to handle multiple Registered Homenet Domains, whereas Appendix A.3 does not have such a requirement.
このドキュメントで説明されているプロトコルおよびDHCPV6オプションは、複数のISPに接続されたHNAと完全に互換性があります。HNAを構成するかどうか、およびHNAの構成方法は、HNA施設に依存します。付録A.1およびA.2では、HNAが複数の登録済みホメネットドメインを処理する必要がありますが、付録A.3にはそのような要件がありません。
We would like to thank Marcin Siodelski, Bernie Volz, and Ted Lemon for their comments on the design of the DHCPv6 options. We would also like to thank Mark Andrews, Andrew Sullivan, and Lorenzo Colliti for their remarks on the architecture design. The designed solution has been largely inspired by Mark Andrews's document [PD-REVERSE] as well as discussions with Mark. We also thank Ray Hunter and Michael Richardson for their reviews and comments and for suggesting appropriate terminology.
DHCPV6オプションの設計に関するコメントについて、Marcin Siodelski、Bernie Volz、およびTed Lemonに感謝します。また、マークアンドリュース、アンドリューサリバン、ロレンツォコリティに、建築デザインに関する発言についても感謝します。設計されたソリューションは、Mark Andrewsの文書[PD-Reverse]とMarkとの議論に大きく触発されています。また、Ray HunterとMichael Richardsonのレビューとコメント、そして適切な用語を提案してくれたことに感謝します。
The coauthors would like to thank Chris Griffiths and Wouter Cloetens for providing significant contributions to the early draft versions of this document.
共著者は、このドキュメントの初期ドラフトバージョンに多大な貢献を提供してくれたChris GriffithsとWouter Cloetensに感謝したいと思います。
Daniel Migault
Ericsson
8275 Trans Canada Route
Saint Laurent QC 4S 0B6
Canada
Email: daniel.migault@ericsson.com
Ralf Weber
Akamai
Email: ralf.weber@akamai.com
Tomek Mrugalski
Internet Systems Consortium, Inc.
PO Box 360
Newmarket, NH 03857
United States of America
Email: tomasz.mrugalski@gmail.com