Internet Engineering Task Force (IETF) L. Colitti
Request for Comments: 9762 J. Linkova
Updates: 4861, 4862 X. Ma, Ed.
Category: Standards Track Google
ISSN: 2070-1721 D. Lamparter
NetDEF, Inc.
June 2025
This document defines the P flag in the Prefix Information Option (PIO) of IPv6 Router Advertisements (RAs). The flag is used to indicate that the network prefers that clients use the deployment model in RFC 9663 instead of using individual addresses in the on-link prefix assigned using Stateless Address Autoconfiguration (SLAAC) or DHCPv6 address assignment.
このドキュメントでは、IPv6ルーター広告（RAS）のプレフィックス情報オプション（PIO）のPフラグを定義します。フラグは、ネットワークが、Stateless Address Autoconfiguration（SLAAC）またはDHCPV6アドレスの割り当てを使用して割り当てられたオンリンクプレフィックスで個々のアドレスを使用する代わりに、クライアントがRFC 9663の展開モデルを使用することを好むことを示すために使用されます。
This document updates RFC 4862 to indicate that the Autonomous flag in a PIO needs to be ignored if the PIO has the P flag set. It also updates RFC 4861 to specify that the P flag indicates DHCPv6 prefix delegation support for clients.
このドキュメントは、RFC 4862を更新して、PIOのPIOにPフラグが設定されている場合、PIOの自律フラグを無視する必要があることを示します。また、RFC 4861を更新して、PフラグがクライアントのDHCPV6プレフィックス委任サポートを示していることを指定します。
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/rfc9762.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9762で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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. Requirements Language
3. Terminology
4. Rationale
5. P Flag Overview
6. Router Behavior
7. Client Behavior
7.1. Processing the P Flag
7.2. Using Delegated Prefix(es)
7.3. Absence of PIOs with the P Bit Set
7.4. On-Link Communication
7.5. Source Address Selection
8. Multihoming
9. Modifications to RFC-Mandated Behavior
9.1. Changes to RFC 4861
9.2. Changes to RFC 4862
10. Security Considerations
11. Privacy Considerations
12. IANA Considerations
13. References
13.1. Normative References
13.2. Informative References
Acknowledgements
Authors' Addresses
[RFC9663] documents an IPv6 address assignment model where IPv6 devices obtain dedicated prefixes from the network via DHCPv6 prefix delegation (DHCPv6-PD) [RFC8415]. This model provides devices with a large IPv6 address space they can use to create addresses for communication, individually number virtual machines (VMs) or containers, or extend the network to downstream devices. It also provides scalability benefits on large networks because network infrastructure devices do not need to maintain per-address state, such as IPv6 neighbor cache, Source Address Validation Improvement (SAVI) [RFC7039] mappings, Virtual eXtensible Local Area Network (VXLAN) [RFC7348] routes, etc.
[RFC9663]は、IPv6デバイスがDHCPV6プレフィックス代表団（DHCPV6-PD）[RFC8415]を介してネットワークから専用のプレフィックスを取得するIPv6アドレス割り当てモデルを文書化します。このモデルは、コミュニケーションのアドレスを作成するために使用できる大きなIPv6アドレススペースをデバイスに提供し、個別に仮想マシン（VM）またはコンテナ、またはネットワークをダウンストリームデバイスに拡張します。また、ネットワークインフラストラクチャデバイスは、IPv6ネイバーキャッシュ、ソースアドレス検証改善（SAVI）[RFC7039]マッピング、仮想拡張可能なローカルエリアネットワーク（VXLAN）[RFC7348]など、アドドレスごとの状態を維持する必要がないため、大規模なネットワークでスケーラビリティの利点を提供します。
On networks with fewer devices, however, this model may not be appropriate, because scaling to support multiple individual IPv6 addresses per device is less of a concern. Also, many home networks currently offer prefix delegation but assume that a limited number of specialized devices and/or applications will require delegated prefixes and thus do not allocate enough address space to offer prefixes to every device that connects to the network. For example, if clients assume the [RFC9663] deployment model on a home network that only receives a /60 from the ISP and each client obtains a /64 prefix, then the network will run out of prefixes after 15 devices have been connected.
ただし、デバイスが少ないネットワークでは、デバイスごとに複数の個々のIPv6アドレスをサポートするためのスケーリングは懸念事項ではないため、このモデルは適切ではない場合があります。また、多くのホームネットワークは現在プレフィックス委任を提供していますが、限られた数の専門デバイスやアプリケーションには委任されたプレフィックスが必要であるため、ネットワークに接続するすべてのデバイスにプレフィックスを提供するのに十分なアドレススペースを割り当てないと仮定します。たとえば、クライアントがISPからA /60のみを受信し、各クライアントがA /64プレフィックスを取得するホームネットワーク上の[RFC9663]展開モデルを想定した場合、15のデバイスが接続された後、ネットワークはプレフィックスを使い果たします。
Therefore, to safely roll out the support of the deployment model defined in [RFC9663] on the client side, it is necessary to have a mechanism for the network to signal to the client which address assignment method is preferred.
したがって、クライアント側の[RFC9663]で定義されている展開モデルのサポートを安全に展開するには、ネットワークが割り当て方法をアドレス指定するクライアントに信号を送信するメカニズムを持つ必要があります。
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」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
Node:
ノード：
a device that implements IPv6 [RFC8200]
IPv6 [RFC8200]を実装するデバイス
Host:
ホスト：
any node that is not a router [RFC8200]
ルーターではないノード[RFC8200]
Client:
クライアント:
a node that connects to a network and acquires addresses. The node may wish to obtain addresses for its own use, or it may be a router that wishes to extend the network to its physical or virtual subsystems, or both. It may be either a host or a router as defined by [RFC8200].
ネットワークに接続してアドレスを取得するノード。ノードは、独自の使用のためにアドレスを取得したい場合があります。または、ネットワークを物理的または仮想サブシステム、またはその両方に拡張したいルーターである場合があります。[RFC8200]で定義されているホストまたはルーターのいずれかです。
DHCPv6-PD:
dhcpv6-pd：
DHCPv6 Prefix Delegation [RFC8415]; a mechanism to delegate IPv6 prefixes to clients.
DHCPV6プレフィックス委任[RFC8415];IPv6プレフィックスをクライアントに委任するメカニズム。
DHCPv6 IA_NA:
dhcpv6 ia_na：
Identity Association for Non-temporary Addresses (Section 21.4 of [RFC8415])
非同時住所のためのアイデンティティ協会（[RFC8415]のセクション21.4）
DHCPv6 IA_PD:
dhcpv6 ia_pd：
Identity Association for Prefix Delegation (Section 21.21 of [RFC8415])
接頭辞委任のアイデンティティ協会（[RFC8415]のセクション21.21）
ND:
ND:
Neighbor Discovery [RFC4861]
隣人発見[RFC4861]
On-link address:
オンリンクアドレス：
an address that is assigned to an interface on a specified link [RFC4861]
指定されたリンクのインターフェイスに割り当てられたアドレス[RFC4861]
On-link prefix:
オンリンクプレフィックス：
a prefix that is assigned to a specified link
指定されたリンクに割り当てられたプレフィックス
Off-link:
オフリンク：
the opposite of "on-link" (see [RFC4861])
「オンリンク」の反対（[rfc4861]を参照）
PIO:
PIO:
Prefix Information Option [RFC4862]
プレフィックス情報オプション[RFC4862]
RA:
RA:
Router Advertisement [RFC4861]
ルーター広告[RFC4861]
SLAAC:
Slaac：
Stateless Address Autoconfiguration [RFC4862]
ステートレスアドレスAutoconfiguration [RFC4862]
The network administrator might want to indicate to clients that requesting a prefix via DHCPv6-PD and using that prefix for address assignment (see [RFC9663]) should be preferred over using individual addresses from the on-link prefix. The information is passed to the client via a P flag in the PIO. The reasons for it being a PIO flag are as follows:
ネットワーク管理者は、DHCPV6-PDを介してプレフィックスを要求し、アドレスの割り当てにそのプレフィックスを使用すること（[RFC9663]を参照）を使用することをクライアントに示したい場合があります。情報は、PIOのPフラグを介してクライアントに渡されます。それがPIOフラグである理由は次のとおりです。
* The information must be contained in the RA because it must be available to the client before it decides to form IPv6 addresses from the PIO prefix using SLAAC. Otherwise, the client might use SLAAC to form IPv6 addresses from the PIO provided and start using them, even if a unique per-client prefix is available via DHCPv6-PD. Forming addresses via SLAAC is suboptimal because if the client later acquires a prefix using DHCPv6-PD, it can either 1) use both the prefix and SLAAC addresses, reducing the scalability benefits of using DHCPv6-PD, or 2) remove the SLAAC addresses, which would be disruptive for applications that are using them.
* SLAACを使用してPIOプレフィックスからIPv6アドレスを形成する前にクライアントが利用できる必要があるため、情報はRAに含まれる必要があります。それ以外の場合、クライアントは、DHCPV6-PDを介して利用可能である場合でも、SLAACを使用して、提供されたPIOからIPv6アドレスを形成し、それらを使用し始めます。SLAACを介したアドレスの形成は、クライアントが後でDHCPV6-PDを使用してプレフィックスを取得する場合、1）プレフィックスアドレスとSLAACアドレスの両方を使用してDHCPV6-PDを使用することのスケーラビリティ利点を減らすことができるため、2）SLAACアドレスを削除するため、それらを使用するSLAACアドレスを削除するため、SLAACを介してアドレスを形成することは最適です。
* This information is specific to the particular prefix being announced. For example, a network administrator might want clients to assign global addresses from delegated prefixes but form Unique Local IPv6 Unicast Addresses [RFC4193] from another PIO in the RA using SLAAC. Also, in a multihoming situation, one upstream network might choose to assign prefixes via prefix delegation and another via PIOs.
* この情報は、発表されている特定のプレフィックスに固有です。たとえば、ネットワーク管理者は、クライアントに委任されたプレフィックスからグローバルアドレスを割り当てることを望む場合がありますが、SLAACを使用してRAの別のPIOから一意のローカルIPv6ユニキャストアドレス[RFC4193]を形成します。また、マルチホームの状況では、1つの上流ネットワークがプレフィックス委任を介してプレフィックスを割り当てることを選択する場合があります。
Note that setting the P flag in a PIO expresses the network operator's preference that clients should attempt using DHCPv6-PD instead of performing individual address configuration on the prefix. For clients that honor this preference by requesting prefix delegation, the actual delegated prefix will necessarily be a prefix different from the one from the PIO.
PIOでPフラグを設定すると、プレフィックスで個々のアドレス構成を実行する代わりに、クライアントがDHCPV6-PDを使用して試みる必要があるというネットワークオペレーターの好みを表していることに注意してください。プレフィックス委任を要求することでこの好みを尊重するクライアントの場合、実際の委任されたプレフィックスは、必然的にPIOのプレフィックスとは異なるプレフィックスになります。
The P flag (also called the DHCPv6-PD Preferred Flag) is a 1-bit PIO flag, located after the R flag [RFC6275]. The presence of a PIO with the P flag set indicates that the network prefers that clients use prefix delegation instead of acquiring individual addresses via SLAAC or DHCPv6 address assignment. This implies that the network has a DHCPv6 server capable of making DHCPv6 prefix delegations to every device on the network, as described in [RFC9663].
Pフラグ（DHCPV6-PD優先フラグとも呼ばれます）は、Rフラグ[RFC6275]の後にある1ビットPIOフラグです。Pフラグセットを備えたPIOの存在は、ネットワークがSLAACまたはDHCPV6アドレスの割り当てを介して個々のアドレスを取得する代わりに、クライアントがプレフィックス委任を使用することを好むことを示しています。これは、ネットワークに[RFC9663]で説明されているように、ネットワーク上のすべてのデバイスにDHCPV6プレフィックス委任を作成できるDHCPV6サーバーがあることを意味します。
Figure 1 shows the resulting format of the PIO.
図1は、PIOの結果の形式を示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |L|A|R|P| Rsvd1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
The P flag is independent of the value of the M and O flags in the RA. If the network desires to delegate prefixes to devices that support DHCPv6 prefix delegation but do not support the P flag, it SHOULD also set the M or O bits in the RA to 1, because some devices, such as Customer Edge (CE) routers [RFC7084], might not initiate DHCPv6 prefix delegation if both the M and O bits are set to zero.
Pフラグは、RAのMおよびOフラグの値に依存しません。ネットワークがDHCPV6プレフィックス委任をサポートしているがPフラグをサポートしないデバイスにプレフィックスを委任したい場合は、顧客エッジ（CE）ルーター[RFC7084]などの一部のデバイスがDHCPV6のプレフィックス委任がZloに設定されている場合にDHCPV6プレフィックス委任を開始しないため、RAのMまたはOビットをRAに設定する必要があります。
Routers SHOULD set the P flag to zero by default, unless explicitly configured by the administrator, and SHOULD allow the operator to set the P flag value for any given prefix advertised in a PIO. Routers MUST allow the P flag to be configured separately from the A flag. In particular, enabling or disabling the P flag MUST NOT trigger automatic changes in the A flag value set by the router.
ルーターは、管理者によって明示的に構成されていない限り、デフォルトでPフラグをゼロに設定し、オペレーターがPIOで宣伝されている特定のプレフィックスのPフラグ値を設定できるようにする必要があります。ルーターは、PフラグをAフラグとは別に構成する必要があります。特に、Pフラグの有効化または無効化は、ルーターによって設定されたAフラグ値の自動変更をトリガーしてはなりません。
This specification only applies to clients that support DHCPv6 prefix delegation. Clients that do not support DHCPv6 prefix delegation MUST ignore the P flag. The P flag is meaningless for link-local prefixes, and any PIO containing the link-local prefix MUST be ignored as specified in Section 5.5.3 of [RFC4862]. In the following text, all prefixes are assumed not to be link-local.
この仕様は、DHCPV6プレフィックス委任をサポートするクライアントにのみ適用されます。DHCPV6プレフィックス委任をサポートしていないクライアントは、Pフラグを無視する必要があります。Pフラグはリンクローカルプレフィックスでは無意味であり、[RFC4862]のセクション5.5.3で指定されているように、リンク局所プレフィックスを含むPIOを無視する必要があります。次のテキストでは、すべてのプレフィックスはリンクローカルではないと想定されています。
For each interface, the client MUST keep a list of every prefix that was received from a PIO with the P flag set and currently has a non-zero preferred lifetime. The list affects the behavior of the DHCPv6 client as follows:
各インターフェイスについて、クライアントは、Pフラグセットを備えたPIOから受信されたすべてのプレフィックスのリストを保持する必要があり、現在はゼロではない寿命があります。このリストは、次のようにDHCPV6クライアントの動作に影響します。
* When a prefix's preferred lifetime becomes zero, either because the preferred lifetime expires or because the client receives a PIO for the prefix with a zero preferred lifetime, the prefix MUST be removed from the list.
* 優先寿命の有効期限が切れるか、クライアントが優先寿命がゼロのプレフィックスのPIOを受信したため、プレフィックスの優先寿命がゼロになると、プレフィックスをリストから削除する必要があります。
* When the length of the list increases to one, the client SHOULD start requesting prefixes via DHCPv6 prefix delegation unless it is already doing so.
* リストの長さが1に増加すると、クライアントは、既に行っていない限り、DHCPV6プレフィックス委任を介してプレフィックスの要求を開始する必要があります。
* When the length of the list decreases to zero, the client SHOULD stop requesting or renewing prefixes via DHCPv6 prefix delegation if it has no other reason to do so. The lifetimes of any prefixes already obtained via DHCPv6 are unaffected.
* リストの長さがゼロに減少した場合、クライアントは、他の理由がない場合は、DHCPV6プレフィックス委任を介してプレフィックスの要求または更新を停止する必要があります。dhcpv6を介して既に取得された任意のプレフィックスの寿命は影響を受けません。
* If the client has already received delegated prefix(es) from one or more servers, then any time one or more prefix(es) are added to or removed from the list, the client MUST consider this to be a change in configuration information as described in Section 18.2.12 of [RFC8415]. In that case, the client MUST perform a REBIND, unless the list is now empty. This is in addition to performing a REBIND in the other cases required by that section. Issuing a REBIND allows the client to obtain new prefixes if necessary, for example, when the network is being renumbered. It also refreshes the state related to the delegated prefix(es).
* クライアントが既に1つ以上のサーバーから委任されたプレフィックス（ES）を既に受信している場合、1つ以上のプレフィックスがリストに追加または削除された場合、クライアントは[RFC8415]のセクション18.2.12で説明されているように、これを構成情報の変更と見なす必要があります。その場合、リストが空になっていない限り、クライアントはリベンドを実行する必要があります。これは、そのセクションで要求されている他のケースで再バインドを実行することに追加されます。Rebindを発行することにより、クライアントは、たとえば、必要に応じて、ネットワークの名前を変更されたときに新しいプレフィックスを取得できます。また、委任されたプレフィックス（es）に関連する状態を再表示します。
When a client requests a prefix via DHCPv6-PD, it MUST use the prefix length hint (Section 18.2.4 of [RFC8415]) to request a prefix that is short enough to form addresses via SLAAC.
クライアントがDHCPV6-PDを介してプレフィックスを要求する場合、プレフィックスの長さヒント（[RFC8415]のセクション18.2.4）を使用して、SLAACを介してアドレスを形成するのに十分な短いプレフィックスを要求する必要があります。
In order to achieve the scalability benefits of using DHCPv6-PD, the client SHOULD prefer to form addresses from the delegated prefix instead of using individual addresses in the on-link prefix(es). Therefore, when the client requests a prefix using DHCPv6-PD, the client SHOULD NOT use SLAAC to obtain IPv6 addresses from PIOs with the P and A bits set. Similarly, if all PIOs processed by the client have the P bit set, the client SHOULD NOT request individual IPv6 addresses from DHCPv6, i.e., it SHOULD NOT include any IA_NA options in Solicit messages [RFC8415]. The client MAY continue to use addresses that are already configured.
DHCPV6-PDを使用することのスケーラビリティ利点を達成するために、クライアントは、オンリンクプレフィックス（ES）で個々のアドレスを使用する代わりに、委任されたプレフィックスからアドレスを形成することを好む必要があります。したがって、クライアントがDHCPV6-PDを使用してプレフィックスを要求した場合、クライアントはSLAACを使用してPIOSからIPv6アドレスを取得してはなりません。同様に、クライアントによって処理されたすべてのPIOがPビットセットを持っている場合、クライアントはDHCPv6から個々のIPv6アドレスを要求してはなりません。つまり、勧誘メッセージにIA_NAオプションを含めるべきではありません[RFC8415]。クライアントは、既に構成されているアドレスを引き続き使用できます。
If the client does not obtain any suitable prefixes via DHCPv6-PD that are suitable for SLAAC, it MAY choose to disable further processing of the P flag on that interface, allowing the client to fall back to other address assignment mechanisms, such as forming addresses via SLAAC (if the PIO has the A flag set to 1) and/or requesting individual addresses via DHCPv6.
クライアントがSLAACに適したDHCPV6-PDを介して適切な接頭辞を取得しない場合、そのインターフェイス上のPフラグのさらなる処理を無効にして、クライアントがSLAACを介したアドレスを形成するなど、他のアドレスの割り当てメカニズムにフォールバックできるようにすることができます（PIOがAフラグを1に設定している場合）。
If the delegated prefix is too long to be used for SLAAC, the client MUST ignore it, as Section 7 of [RFC9663] requires the network to provide a SLAAC-suitable prefix to clients. If the prefix is shorter than required for SLAAC, the client SHOULD accept it, allocate one or more longer prefixes suitable for SLAAC, and use the prefixes as described below.
[RFC9663]のセクション7では、クライアントにSLAACに適したプレフィックスを提供するためにネットワークが必要とするため、委任されたプレフィックスをSLAACに使用するには長すぎる場合、クライアントはそれを無視する必要があります。接頭辞がSLAACに必要よりも短い場合、クライアントはそれを受け入れ、SLAACに適した1つ以上の長いプレフィックスを割り当て、以下に説明するようにプレフィックスを使用する必要があります。
For every accepted prefix:
受け入れられているすべてのプレフィックスについて：
* The client MAY form as many IPv6 addresses from the prefix as it chooses.
* クライアントは、選択したプレフィックスから多くのIPv6アドレスを形成する場合があります。
* The client MAY use the prefix to provide IPv6 addresses to internal components such as VMs or containers.
* クライアントは、プレフィックスを使用して、VMやコンテナなどの内部コンポーネントにIPv6アドレスを提供できます。
* The client MAY use the prefix to allow devices directly connected to it to obtain IPv6 addresses. For example, the client MAY route traffic for that prefix to an interface and send an RA containing a PIO for the prefix on that interface. That interface MUST NOT be the interface the prefix is obtained from. If the client advertises the prefix on an interface and it has formed addresses from the prefix, then it MUST act as though the addresses were assigned to that interface for the purposes of Neighbor Discovery and Duplicate Address Detection.
* クライアントは、プレフィックスを使用して、デバイスを直接接続してIPv6アドレスを取得できるようにすることができます。たとえば、クライアントはそのプレフィックスのトラフィックをインターフェイスにルーティングし、そのインターフェイス上のプレフィックス用のPIOを含むRAを送信する場合があります。そのインターフェイスは、プレフィックスが取得されるインターフェイスであってはなりません。クライアントがインターフェイス上のプレフィックスを宣伝し、プレフィックスからアドレスを形成した場合、アドレスが近隣の発見と複製アドレス検出の目的でそのインターフェイスに割り当てられたかのように動作する必要があります。
The client MUST NOT send or forward packets with destination addresses within a delegated prefix to the interface that it obtained the prefix on, as this can cause a routing loop. This problem will not occur if the client has assigned the prefix to another interface. Another way the client can prevent this problem is to add to its routing table a high-metric discard route for the delegated prefix.
クライアントは、プレフィックスを取得したインターフェイスに委任されたプレフィックス内に宛先アドレスを含むパケットを送信または転送してはなりません。これにより、ルーティングループが発生する可能性があります。クライアントがプレフィックスを別のインターフェイスに割り当てた場合、この問題は発生しません。クライアントがこの問題を防ぐことができるもう1つの方法は、委任されたプレフィックスの高メトリック破棄ルートをルーティングテーブルに追加することです。
The P bit is purely a positive indicator, telling nodes that DHCPv6 prefix delegation is available and the network prefers that nodes use it, even if they do not have any other reason to run a prefix delegation client. The absence of any PIOs with the P bit does not carry any kind of signal to the opposite and MUST NOT be processed to mean that DHCPv6-PD is absent. In particular, nodes that run DHCPv6-PD due to explicit configuration or by default (e.g., to extend the network) MUST NOT disable DHCPv6-PD on the absence of PIOs with the P bit set. A very common example of this are CE routers as described by [RFC7084].
Pビットは純粋に正の指標であり、DHCPV6プレフィックス委任が利用可能であり、ネットワークがプレフィックス委任クライアントを実行する他の理由がない場合でも、ネットワークがそれを使用することを好むことをノードに伝えます。P BITのPIOがないことは、反対の信号を運ぶことはなく、DHCPV6-PDが存在しないことを意味するように処理してはなりません。特に、明示的な構成またはデフォルトでDHCPV6-PDを実行するノード（たとえば、ネットワークを拡張するため）は、Pビットセットを備えたPIOの不在でDHCPV6-PDを無効にしてはなりません。これの非常に一般的な例は、[RFC7084]で説明されているようにCEルーターです。
When the network delegates unique prefixes to clients, each client will consider other clients' destination addresses to be off-link, because those addresses are from the delegated prefixes and are not within any on-link prefix. When a client sends traffic to another client, packets will initially be sent to the default router. The router may respond with an ICMPv6 redirect message (Section 4.5 of [RFC4861]). If the client receives and accepts the redirect, then traffic can flow directly from device to device. Therefore, hosts supporting the P flag SHOULD process redirects unless configured otherwise. Hosts that do not process ICMPv6 redirects, and routers that do not act on ICMPv6 redirects, may experience higher latency while communicating to prefixes delegated to other clients on the same link.
ネットワークがクライアントに一意のプレフィックスを委任する場合、各クライアントは他のクライアントの宛先アドレスがリンクオフリンクであると見なします。これらのアドレスは委任されたプレフィックスからであり、リンクオンプレフィックス内にないためです。クライアントがトラフィックを別のクライアントに送信すると、パケットは最初にデフォルトのルーターに送信されます。ルーターは、ICMPV6リダイレクトメッセージ（[RFC4861]のセクション4.5）で応答する場合があります。クライアントがリダイレクトを受信して受け入れると、トラフィックはデバイスからデバイスに直接流れる可能性があります。したがって、Pフラグをサポートするホストは、特に構成されていない限り、リダイレクトを処理する必要があります。ICMPV6リダイレクトを処理しないホスト、およびICMPV6リダイレクトに作用しないルーターは、同じリンクの他のクライアントに委任された接頭辞に通信しながら、より高い遅延を発生する場合があります。
For the purpose of source address selection [RFC6724], if the host creates any addresses from a delegated prefix, it SHOULD treat those addresses as if they were assigned to the interface on which the prefix was received. This includes placing them in the candidate set and associating them with the outgoing interface when implementing Rule 5 of the source address selection algorithm [RFC6724].
ソースアドレスの選択[RFC6724]のために、ホストが委任されたプレフィックスからアドレスを作成する場合、それらのアドレスがプレフィックスが受信されたインターフェイスに割り当てられているかのようにそれらのアドレスを扱う必要があります。これには、ソースアドレス選択アルゴリズム[RFC6724]のルール5を実装する際に、それらを候補セットに配置し、発信インターフェイスに関連付けることが含まれます。
In multi-prefix multihoming, the host generally needs to associate the prefix with the router that advertised it (for example, see Rule 5.5 in [RFC6724]). If the host supports Rule 5.5, then it SHOULD associate each prefix with the link-local address of the DHCPv6 server or relay from which it received the REPLY packet. When receiving multiple REPLYs carrying the same prefix from distinct link-local addresses, the host SHOULD associate that prefix with all of these addresses. This can commonly happen in networks with redundant routers and DHCPv6 servers or relays.
Multi-Prefix Multihomingでは、ホストは通常、プレフィックスを宣伝したルーターに関連付ける必要があります（たとえば、[RFC6724]のルール5.5を参照）。ホストがルール5.5をサポートする場合、各プレフィックスをDHCPV6サーバーのリンクローカルアドレスに関連付けるか、Replyパケットを受信したリレーに関連付ける必要があります。個別のリンクローカルアドレスから同じプレフィックスを運ぶ複数の返信を受信する場合、ホストはそのプレフィックスをこれらのアドレスのすべてに関連付ける必要があります。これは、一般に、冗長ルーターとDHCPV6サーバーまたはリレーを備えたネットワークで発生する可能性があります。
This document makes the following changes to Section 4.2 of [RFC4861]:
このドキュメントは、[RFC4861]のセクション4.2に次の変更を加えます。
OLD TEXT:
古いテキスト：
Note: If neither M nor O flags are set, this indicates that no information is available via DHCPv6.
注：MもOフラグも設定されていない場合、これはDHCPV6を介して利用可能な情報がないことを示します。
NEW TEXT:
新しいテキスト：
Note: If the M, O, or P (RFC 9762) flags are not set, this indicates that no information is available via DHCPv6.
注：M、O、またはP（RFC 9762）フラグが設定されていない場合、これはDHCPV6を介して利用可能な情報がないことを示しています。
This document makes the following changes to Section 5.5.3 of [RFC4862]:
このドキュメントは、[RFC4862]のセクション5.5.3に次の変更を加えます。
OLD TEXT:
古いテキスト：
For each Prefix-Information option in the Router Advertisement:
ルーター広告の各プレフィックス情報オプションについて：
a) If the Autonomous flag is not set, silently ignore the Prefix Information option.
a) 自律フラグが設定されていない場合、プレフィックス情報オプションを静かに無視します。
b) If the prefix is the link-local prefix, silently ignore the Prefix Information option.
b) プレフィックスがリンクローカルプレフィックスである場合、プレフィックス情報オプションを静かに無視します。
c) If the preferred lifetime is greater than the valid lifetime, silently ignore the Prefix Information option. A node MAY wish to log a system management error in this case.
c) 優先寿命が有効な寿命よりも大きい場合、プレフィックス情報オプションを静かに無視します。この場合、ノードはシステム管理エラーを記録することをお勧めします。
d) If the prefix advertised is not equal to the prefix of an address configured by stateless autoconfiguration already in the list of addresses associated with the interface (where "equal" means the two prefix lengths are the same and the first prefix-length bits of the prefixes are identical), and if the Valid Lifetime is not 0, form an address (and add it to the list) by combining the advertised prefix with an interface identifier of the link as follows:
d) 宣伝されているプレフィックスが、インターフェイスに関連付けられているアドレスのリストに既にステートレスオートコンチュレーションによって構成されたアドレスのプレフィックスに等しくない場合（「等」ということは、2つのプレフィックスの長さが同じであることを意味し、プレフィックスの最初のプレフィックス長ビットは同じです）、および有効な寿命は0ではない場合（およびアドレスを組み合わせたアドレスに添加します）。
NEW TEXT:
新しいテキスト：
For each Prefix Information Option in the Router Advertisement:
ルーター広告の各プレフィックス情報オプションについて：
a) If the prefix is the link-local prefix, silently ignore the Prefix Information Option.
a) プレフィックスがリンクローカルプレフィックスである場合、プレフィックス情報オプションを静かに無視します。
b) If the P flag is set and the node implements RFC 9762, it SHOULD treat the Autonomous flag as if it was unset and use prefix delegation to obtain addresses as described in RFC 9762.
b) Pフラグが設定され、ノードがRFC 9762を実装する場合、自律フラグを設定していないかのように扱い、RFC 9762で説明されているようにアドレスを取得するためにプレフィックス委任を使用する必要があります。
c) If the Autonomous flag is not set, silently ignore the Prefix Information Option.
c) 自律フラグが設定されていない場合、プレフィックス情報オプションを静かに無視します。
d) If the preferred lifetime is greater than the valid lifetime, silently ignore the Prefix Information Option. A node MAY wish to log a system management error in this case.
d) 優先寿命が有効な寿命よりも大きい場合、プレフィックス情報オプションを静かに無視します。この場合、ノードはシステム管理エラーを記録することをお勧めします。
e) If the prefix advertised is not equal to the prefix of an address configured by stateless autoconfiguration already in the list of addresses associated with the interface (where "equal" means the two prefix lengths are the same and the first prefix-length bits of the prefixes are identical) and if the Valid Lifetime is not 0, form an address (and add it to the list) by combining the advertised prefix with an interface identifier of the link as follows:
e) 宣伝されているプレフィックスが、インターフェイスに関連付けられたアドレスのリストに既にStateless Autoconfigurationで構成されたアドレスのプレフィックスに等しくない場合（「等」ということは、2つのプレフィックスの長さが同じであることを意味し、最初のプレフィックス長ビットは同一であり、有効な寿命は0ではない場合（およびアドレスを結合します）。
The mechanism described in this document relies on the information provided in the RA and therefore shares the same security model as SLAAC. If the network does not implement RA-Guard [RFC6105], an attacker might send RAs containing the PIO used by the network, set the P flag to 1, and force hosts to ignore the A flag. In the absence of DHCPv6-PD infrastructure, hosts would either obtain no IPv6 addresses or, if they fall back to other IPv6 address assignment mechanisms such as SLAAC and IA_NA, would experience delays in obtaining IPv6 addresses. If the network does not support DHCPv6-Shield [RFC7610], the attacker could also run a rogue DHCPv6 server, providing the host with invalid prefixes or other invalid configuration information.
このドキュメントで説明されているメカニズムは、RAで提供される情報に依存しているため、SLAACと同じセキュリティモデルを共有しています。ネットワークがRAガード[RFC6105]を実装していない場合、攻撃者はネットワークで使用されるPIOを含むRASを送信し、Pフラグを1に設定し、ホストにAフラグを無視するように強制する場合があります。DHCPV6-PDインフラストラクチャがない場合、ホストはIPv6アドレスを取得しないか、SLAACやIA_NAなどの他のIPv6アドレスの割り当てメカニズムに戻ると、IPv6アドレスの取得が遅れます。ネットワークがDHCPV6-Shield [RFC7610]をサポートしていない場合、攻撃者はRogue DHCPV6サーバーを実行し、ホストに無効な接頭辞またはその他の無効な構成情報を提供することもできます。
The attacker might force hosts to oscillate between DHCPv6-PD and PIO-based SLAAC by sending the same set of PIOs with and then without the P flag set. That would cause the clients to issue REBIND requests, increasing the load on the DHCP infrastructure. However, Section 14.1 of [RFC8415] requires that DHCPv6-PD clients rate-limit transmitted DHCPv6 messages.
攻撃者は、同じピオのセットをPフラグセットなしで送信することにより、ホストにDHCPV6-PDとPIOベースのSLAACの間の振動を強制する場合があります。そのため、クライアントはリクエストの再生成を発行し、DHCPインフラストラクチャの負荷が増加します。ただし、[RFC8415]のセクション14.1では、DHCPV6-PDクライアントのレートリミット送信DHCPV6メッセージが必要です。
It should be noted that if the network allows rogue RAs to be sent, the attacker would be able to disrupt hosts' connectivity anyway, so this document doesn't introduce any fundamentally new security considerations.
ネットワークがRogue RAを送信することを許可した場合、攻撃者はとにかくホストの接続性を混乱させることができるため、このドキュメントでは根本的に新しいセキュリティ上の考慮事項が導入されないことに注意する必要があります。
Security considerations inherent to the PD-per-device model are documented in Section 15 of [RFC9663].
Device Pers-Per-Deviceモデルに固有のセキュリティ上の考慮事項は、[RFC9663]のセクション15に記載されています。
The privacy implications of implementing the P flag and using DHCPv6-PD to assign prefixes to hosts are similar to the privacy implications of using DHCPv6 to assign individual addresses. If the DHCPv6 infrastructure assigns the same prefix to the same client, then an observer might be able to identify clients based on the highest 64 bits of the client's address. Those implications and recommended countermeasures are discussed in Section 13 of [RFC9663].
Pフラグを実装し、DHCPV6-PDを使用してプレフィックスをホストに割り当てることのプライバシーへの影響は、DHCPV6を使用して個々のアドレスを割り当てることのプライバシーへの影響に似ています。DHCPV6インフラストラクチャが同じクライアントに同じプレフィックスを割り当てる場合、オブザーバーはクライアントのアドレスの最高64ビットに基づいてクライアントを識別できる場合があります。これらの意味と推奨される対策については、[RFC9663]のセクション13で説明します。
Implementing the P flag support on a host and receiving will enable DHCPv6 on that host if the host receives an RA containing a PIO with the P bit set. Sending DHCPv6 packets may reveal some minor additional information about the host, most prominently the hostname. This is not a new concern and would apply for any network that uses DHCPv6 and sets the M flag in RAs.
ホストにP FLAGサポートを実装して受信すると、ホストがPビットセットのPIOを含むRAを受け取った場合、そのホストにDHCPV6が有効になります。DHCPV6パケットを送信すると、ホストに関するいくつかの小さな追加情報が明らかになる場合があります。これは新しい懸念ではなく、DHCPV6を使用してRASにMフラグを設定するネットワークに適用されます。
No privacy considerations result from supporting the P flag on the sender side.
送信者側のPフラグをサポートすることからプライバシーの考慮事項はありません。
IANA has made the following allocation in the "IPv6 Neighbor Discovery Prefix Information Option Flags" registry [RFC8425]:
IANAは、「IPv6 Neighbor Discovery Prefix Information Option Flags」レジストリ[RFC8425]で次の割り当てを行いました。
+================+==============================+===========+
| PIO Option Bit | Description | Reference |
+================+==============================+===========+
| 3 | P - DHCPv6-PD Preferred Flag | RFC 9762 |
+----------------+------------------------------+-----------+
Table 1
[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>.
[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>.
[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>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>.
[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>.
[RFC8425] Troan, O., "IANA Considerations for IPv6 Neighbor
Discovery Prefix Information Option Flags", RFC 8425,
DOI 10.17487/RFC8425, July 2018,
<https://www.rfc-editor.org/info/rfc8425>.
[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>.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
DOI 10.17487/RFC6105, February 2011,
<https://www.rfc-editor.org/info/rfc6105>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
"Source Address Validation Improvement (SAVI) Framework",
RFC 7039, DOI 10.17487/RFC7039, October 2013,
<https://www.rfc-editor.org/info/rfc7039>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084,
DOI 10.17487/RFC7084, November 2013,
<https://www.rfc-editor.org/info/rfc7084>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>.
[RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield:
Protecting against Rogue DHCPv6 Servers", BCP 199,
RFC 7610, DOI 10.17487/RFC7610, August 2015,
<https://www.rfc-editor.org/info/rfc7610>.
[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>.
[RFC9663] Colitti, L., Linkova, J., Ed., and X. Ma, Ed., "Using
DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique
IPv6 Prefixes per Client in Large Broadcast Networks",
RFC 9663, DOI 10.17487/RFC9663, October 2024,
<https://www.rfc-editor.org/info/rfc9663>.
Thanks to Nick Buraglio, Brian Carpenter, Tim Chown, David Farmer, Fernando Gont, Susan Hares, Mahesh Jethanandani, Suresh Krishnan, Ted Lemon, Andrew McGregor, Tomek Mrugalski, Erik Nordmark, Michael Richardson, Patrick Rohr, John Scudder, Ole Trøan, Dirk Von Hugo, Éric Vyncke and Timothy Winters for the discussions, reviews, input, and contributions.
ニック・ブラグリオ、ブライアン・カーペンター、ティム・チャウン、デビッド・ファーマー、フェルナンド・ゴント、スーザン・ハレス、マヘシュ・ジェタナンダニ、スレシュ・クリシュナン、テッド・レモン、アンドリュー・マクレガー、トメク・ムルガルスキ、エリック・ノードマーク、マイケル・リチャードソン、パトリック・ロール、ジョン・スカッデン、ディール・トリック・ヴァン、ディルク・ヴァン、ディスカッション、レビュー、入力、貢献のためのティモシーウィンターズ。
Lorenzo Colitti
Google
Shibuya 3-21-3,
Japan
Email: lorenzo@google.com
Jen Linkova
Google
1 Darling Island Rd
Pyrmont NSW 2009
Australia
Email: furry13@gmail.com, furry@google.com
Xiao Ma (editor)
Google
Shibuya 3-21-3,
Japan
Email: xiaom@google.com
David 'equinox' Lamparter
NetDEF, Inc.
04229 Leipzig
Germany
Email: equinox@diac24.net, equinox@opensourcerouting.org