Internet Engineering Task Force (IETF) T. Winters
Request for Comments: 9818 QA Cafe
Updates: 7084 July 2025
Category: Informational
ISSN: 2070-1721
This document defines requirements for IPv6 Customer Edge (CE) routers to support DHCPv6 Prefix Delegation for distributing available prefixes to LAN devices that were delegated to an IPv6 CE router. This document updates RFC 7084.
このドキュメントは、IPv6 CERTEREDED（CE）ルーターの要件を定義して、IPv6 CEルーターに委任されたLANデバイスに利用可能なプレフィックスを配布するためのDHCPV6プレフィックス委任をサポートします。このドキュメントは、RFC 7084を更新します。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc9818.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9818で取得できます。
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. IPv6 End-User Network Architecture
5. Requirements
5.1. LAN Prefix Delegation Requirements (LPD)
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Author's Address
This document describes guidelines for DHCPv6 Prefix Delegation in IPv6 Customer Edge (CE) routers [RFC7084] in order to properly utilize the IPv6 prefixes delegated by service providers. Many service providers assign larger address blocks than /64 to CE routers, as recommended in [RFC6177]. If an IPv6 CE router does not support the Identity Association for Prefix Delegation (IA_PD) Prefix Option (Section 21.21 of [RFC8415]) on the LAN, it will not be able to assign any prefixes beyond its local interfaces, limiting the usefulness of assigning prefixes larger than /64 by the operator. Supporting IA_PD on the LAN interfaces of a CE router will allow those unused prefixes to be distributed into a network. Note that efforts such as those of the Stub Networking Auto Configuration (SNAC) Working Group depend on IPv6 prefixes being properly distributed in the LAN.
このドキュメントは、サービスプロバイダーによって委任されたIPv6プレフィックスを適切に利用するために、IPv6カスタマーエッジ（CE）ルーター[RFC7084]のDHCPV6プレフィックス委任のガイドラインについて説明します。[RFC6177]で推奨されるように、多くのサービスプロバイダーは、 /64よりも大きなアドレスブロックをCEルーターに割り当てています。IPv6 CEルーターがLAN上のプレフィックス委任（IA_PD）プレフィックスオプション（[RFC8415]のセクション21.21）のID協会をサポートしていない場合、ローカルインターフェイスを超えてプレフィックスを割り当てることはできず、オペレーターによって /64より大きなプレフィックスを割り当てることの有用性を制限することはできません。CEルーターのLANインターフェイスでIA_PDをサポートすることで、これらの未使用のプレフィックスをネットワークに分散させることができます。Stub Networking Auto Configuration（SNAC）ワーキンググループのような努力は、LANに適切に分布しているIPv6プレフィックスに依存することに注意してください。
Two models, hierarchical prefix and flat, were proposed in the past for prefix sub-delegation beyond an IPv6 CE router. Hierarchical prefix delegation requires an IPv6 CE router to sub-delegate IPv6 prefixes based on a set of rules. If more than one router uses hierarchical prefix delegation, an IPv6 prefix tree is created. When no routing protocol is enabled to discover the network topology, it is possible to have an unbalanced prefix delegation tree, which leads to running out of prefixes. More information on hierarchical prefix delegation can be found, e.g., in Section 8.5 of CableLabs IPv6 eRouter specification [eRouter]. A flat prefix delegation requires the router to be provisioned with the initial prefix and to assign /64 prefixes to all other prefix requests from routers in the LAN-facing interface. The default configuration of CE routers is designed to be a flat model to support zero-configuration networking.
階層的なプレフィックスとフラットの2つのモデルが、IPv6 CEルーターを超えたプレフィックスサブディレージングのために過去に提案されました。階層的プレフィックス委任には、一連のルールに基づいてIPv6 CEルーターがIPv6プレフィックスをサブディールする必要があります。複数のルーターが階層プレフィックス委任を使用している場合、IPv6プレフィックスツリーが作成されます。ネットワークトポロジを発見するためにルーティングプロトコルが有効になっていない場合、接頭辞の不均衡なプレフィックス委任ツリーを持つことができます。階層的プレフィックス代表団の詳細については、たとえば、CableLabs IPv6 Erouter仕様のセクション8.5 [erouter]にあります。フラットなプレフィックス委任では、ルーターを初期プレフィックスでプロビジョニングし、LANフェーシングインターフェイスのルーターからの他のすべてのプレフィックスリクエストに /64のプレフィックスを割り当てる必要があります。CEルーターのデフォルト構成は、ゼロコンフィグレーターネットワークをサポートするフラットモデルになるように設計されています。
This document does not cover dealing with multi-prefix networks with more than one provider. Due to the complexity of a solution that would require routing, provisioning, and policy, this is out of scope of this document.
このドキュメントでは、複数のプロバイダーを備えたMulti-Prefixネットワークへの取引については説明していません。ルーティング、プロビジョニング、およびポリシーを必要とするソリューションの複雑さにより、これはこのドキュメントの範囲外です。
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] で説明されているように解釈されます。
This document uses these keywords not strictly for the purpose of interoperability, but rather for the purpose of establishing industry-common baseline functionality. As such, the document points to several other specifications to provide additional guidance to implementers regarding any protocol implementation required to produce a successful CE router that interoperates successfully with a particular subset of currently deployed and planned common IPv6 access networks.
このドキュメントでは、これらのキーワードは、相互運用性の目的ではなく、業界と一般的なベースライン機能を確立する目的で、厳密には使用しています。そのため、ドキュメントは他のいくつかの仕様を指しており、現在展開および計画されている一般的なIPv6アクセスネットワークの特定のサブセットと成功裏に相互運用する成功したCEルーターを生成するために必要なプロトコル実装に関する実装者に追加のガイダンスを提供します。
The document makes use of the following terms, some of which are from Section 2 of [RFC8200].
このドキュメントでは、次の用語を使用しており、その一部は[RFC8200]のセクション2からのものです。
IPv6 node:
IPv6ノード：
A device that implements IPv6.
IPv6を実装するデバイス。
IPv6 router:
IPv6ルーター：
An IPv6 node that forwards IPv6 packets not explicitly addressed to itself.
IPv6パケットを明示的にアドレス指定しないIPv6ノード。
IPv6 host:
IPv6ホスト：
An IPv6 node that is not a router.
ルーターではないIPv6ノード。
ULA:
ULA:
Unique Local Address, as defined in [RFC4193].
[RFC4193]で定義されている独自のローカルアドレス。
GUA:
GUA:
Global Unicast Address, as defined in [RFC4291].
[RFC4291]で定義されているグローバルユニキャストアドレス。
The end-user network for IPv6 contains stub networks. Figure 1 illustrates the model topology.
IPv6用のエンドユーザーネットワークには、スタブネットワークが含まれています。図1は、モデルトポロジを示しています。
+-----------+
| Service |
| Provider |
| Router |
+-----+-----+
|
|
| Customer
| Internet Connection
|
+-----v-----+
| IPv6 |
| CE |
| Router |
+-----+-----+
|
+------+-------+
| |
| |
+---+----+ +-----+-----+
| IPv6 | | |
| Host | | Router |
| | | |
+--------+ +-----+-----+
|
|
+---+----+
| IPv6 |
| Host |
| |
+--------+
Figure 1: Example IPv6 End-User Topology
図1：IPv6エンドユーザートポロジの例
IPv6 CE routers distribute configuration information obtained during WAN interface provisioning to LAN-facing IPv6 hosts and routers. A CE router that is compliant with [RFC7084] would only provide IPv6 hosts with configuration information. This document allows for addressing and routing of IPv6 prefixes to both hosts and routers. These requirements are in addition to the ones in Section 4.3 of [RFC7084].
IPv6 CEルーターWANインターフェイスプロビジョニング中に取得した構成情報をLANに向かうIPv6ホストとルーターに配布します。[RFC7084]に準拠したCEルーターは、IPv6ホストに構成情報のみを提供します。このドキュメントでは、ホストとルーターの両方へのIPv6プレフィックスのアドレス指定とルーティングが可能になります。これらの要件は、[RFC7084]のセクション4.3の要件に追加されます。
LPD-1: Each IPv6 CE router MUST support IPv6 prefix assignment according to Section 13.3 of [RFC8415] (Identity Association for Prefix Delegation (IA_PD) option) on its LAN interface(s).
LPD-1：各IPv6 CEルーターは、[RFC8415]のセクション13.3（IDプレフィックス代表団（IA_PD）オプションのアイデンティティ協会）に従ってIPv6プレフィックス割り当てをサポートする必要があります。
LPD-2: Each IPv6 CE routers MUST assign a prefix from the delegated prefix as specified by L-2 in Section 4.3 of [RFC7084]. If insufficient prefixes are available, the IPv6 CE router MUST log a system management error.
LPD-2：各IPv6 CEルーターは、[RFC7084]のセクション4.3でL-2で指定されているように、委任されたプレフィックスからプレフィックスを割り当てる必要があります。プレフィックスが不十分な場合は、IPv6 CEルーターがシステム管理エラーをログに記録する必要があります。
LPD-3: The prefix assigned to a link MUST NOT change in the absence of a local policy or a topology change.
LPD-3：リンクに割り当てられたプレフィックスは、ローカルポリシーやトポロジの変更がない場合に変更してはなりません。
LPD-4: After LAN link prefix assignments, the IPv6 CE router MUST keep the remaining IPv6 prefixes available to other routers via Prefix Delegation.
LPD-4：LANリンクプレフィックス割り当ての後、IPv6 CEルーターは、プレフィックス委任を介して他のルーターで残りのIPv6プレフィックスを使用できるようにする必要があります。
LPD-5: IPv6 CE routers MUST maintain a local routing table that is dynamically updated with leases and the associated next hops as they are delegated to clients. Absent explicit filtering, packets with destination addresses in a delegated prefix MUST be forwarded to that prefix regardless of which interface they are received on. When a delegated prefix is released or expires, the associated route MUST be removed from the IPv6 CE router's routing table. A delegated prefix expires when the valid lifetime assigned in the IA_PD expires without being renewed. When a prefix is released or expires, it MUST be returned the pool of available prefixes.
LPD-5：IPv6 CEルーターは、クライアントに委任されるため、リースと関連する次のホップで動的に更新されるローカルルーティングテーブルを維持する必要があります。明示的なフィルタリングがなければ、委任されたプレフィックスに宛先アドレスを含むパケットは、受信したインターフェイスに関係なく、そのプレフィックスに転送する必要があります。委任されたプレフィックスがリリースされるか、有効期限が切れる場合、関連するルートをIPv6 CEルーターのルーティングテーブルから削除する必要があります。IA_PDで割り当てられた有効な寿命が更新されずに期限切れになると、委任されたプレフィックスが期限切れになります。接頭辞がリリースまたは有効期限が切れたら、使用可能なプレフィックスのプールを返す必要があります。
LPD-6: By default, the IPv6 CE router filtering rules MUST allow forwarding of packets with an outer IPv6 header containing a source address belonging to delegated prefixes, along with reciprocal packets from the same flow, following the recommendations of [RFC6092]. This updates WPD-5 of [RFC7084] to not drop packets from prefixes that have been delegated. IPv6 CE routers MUST continue to drop packets, including destination address, that are not assigned to the LAN or delegated.
LPD-6：デフォルトでは、IPv6 CEルーターフィルタリングルールでは、[RFC6092]の推奨に従って、同じフローからの相互パケットとともに、委任されたプレフィックスに属するソースアドレスを含む外側のIPv6ヘッダーを使用したパケットの転送を許可する必要があります。これにより、[RFC7084]のWPD-5を更新して、委任されたプレフィックスからパケットをドロップしないようにします。IPv6 CEルーターは、LANに割り当てられていない、または委任された宛先アドレスを含むパケットを引き続きドロップする必要があります。
LPD-7: The IPv6 CE routers MUST provision IA_PD prefixes with a prefix-length of 64 on the LAN-facing interface unless configured to use a different prefix-length by the CE router administrator. The prefix-length of 64 is used as that is the current prefix-length supported by SLAAC [RFC4862]. For hierarchical prefix delegation, a prefix-length shorter than 64 may be configured.
LPD-7：IPv6 CEルーターは、CEルーター管理者によって異なるプレフィックスレングスを使用するように構成されていない限り、LANに向かうインターフェイスに64のプレフィックスレングスをIA_PDプレフィックスを提供する必要があります。64のプレフィックス長は、SLAAC [RFC4862]でサポートされている現在のプレフィックス長であるために使用されます。階層的プレフィックス委任の場合、64より短いプレフィックス長を構成することができます。
LPD-8: IPv6 CE routers configured to generate a ULA prefix as defined in ULA-1 of Section 4.3 of [RFC7084] MUST continue to provision available GUA IPv6 prefixes.
LPD-8：[RFC7084]のセクション4.3のULA-1で定義されているULAプレフィックスを生成するように構成されたIPv6 CEルーターは、利用可能なGUA IPv6プレフィックスを引き続き提供する必要があります。
LPD-9: If an IPv6 CE router is provisioning both a ULA and GUA via prefix delegation, the GUA SHOULD appear first in the DHCPv6 packets.
LPD-9：IPv6 CEルーターがプレフィックス委任を介してULAとGUAの両方をプロビジョニングしている場合、GUAは最初にDHCPV6パケットに表示されるはずです。
LPD-10: IPv6 CE routers MUST NOT delegate prefixes via DHCPv6 on the LAN using lifetimes that exceed the remaining lifetimes of the corresponding prefixes learned on the WAN.
LPD-10：IPv6 CEルーターは、WANで学習した対応するプレフィックスの残りの寿命を超える寿命を使用して、LAN上のDHCPV6を介してプレフィックスを委任してはなりません。
This document does not add any new security considerations beyond those mentioned in Section 4 of [RFC8213], Section 22 of [RFC8415], and Section 6 of [RFC6092].
このドキュメントでは、[RFC8213]のセクション4、[RFC8415]のセクション22、および[RFC6092]のセクション6に記載されているものを超えて、新しいセキュリティ上の考慮事項を追加しません。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[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>.
[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>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[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>.
[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>.
[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>.
[RFC8213] Volz, B. and Y. Pal, "Security of Messages Exchanged
between Servers and Relay Agents", RFC 8213,
DOI 10.17487/RFC8213, August 2017,
<https://www.rfc-editor.org/info/rfc8213>.
[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>.
[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>.
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security
Capabilities in Customer Premises Equipment (CPE) for
Providing Residential IPv6 Internet Service", RFC 6092,
DOI 10.17487/RFC6092, January 2011,
<https://www.rfc-editor.org/info/rfc6092>.
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address
Assignment to End Sites", BCP 157, RFC 6177,
DOI 10.17487/RFC6177, March 2011,
<https://www.rfc-editor.org/info/rfc6177>.
[eRouter] CableLabs, "IPv4 and IPv6 eRouter Specification", Data-
Over-Cable Service Interface Specifications, Version I22,
May 2024,
<https://www.cablelabs.com/specifications/CM-SP-eRouter>.
Thanks to the following people for their guidance and feedback: Marion Dillon, Erik Auerswald, Esko Dijk, Tim Carlin, Richard Patterson, Ted Lemon, Michael Richardson, Martin Huneki, Gabor Lencse, Ole Troan, Brian Carpenter, David Farmer, Kyle Rose, Mohamed Boucadair, Tim Chown, Ron Bonica, and Erica Johnson.
マリオンディロン、エリックアウアースワルド、エスコディーク、ティムカーリン、リチャードパターソン、テッドレモン、マイケルリチャードソン、マーティンフネキ、ガボールレンセ、オレトロアン、ブライアンカーペンター、デイビッドファーマー、モハメドブーケードエアロローズ、ロン、ロン、ロン、ロン、ロン、マイケルリチャードソン、マーティンフネキ、ガボールレンセ、マイケルリチャードソン、マイケルリチャードソン、マイケルリチャードソン、テッドレモン、次の人々に感謝します。
Timothy Winters
QA Cafe
100 Main Street, Suite #212
Dover, NH 03820
United States of America
Email: tim@qacafe.com