Internet Engineering Task Force (IETF) X. Xiao
Request for Comments: 9898 E. Vasilenko
Category: Informational Huawei Technologies
ISSN: 2070-1721 E. Metz
KPN N.V.
G. Mishra
Verizon Inc.
N. Buraglio
Energy Sciences Network
November 2025
The Neighbor Discovery (ND) protocol is a critical component of the IPv6 architecture. The protocol uses multicast in many messages. It also assumes a security model where all nodes on a link are trusted. Such a design might be inefficient in some scenarios (e.g., use of multicast in wireless networks) or when nodes are not trustworthy (e.g., public access networks). These security and operational issues and the associated mitigation solutions are documented in more than twenty RFCs. There is a need to track these issues and solutions in a single document.
近隣探索 (ND) プロトコルは、IPv6 アーキテクチャの重要なコンポーネントです。このプロトコルは多くのメッセージでマルチキャストを使用します。また、リンク上のすべてのノードが信頼されるセキュリティ モデルも前提としています。このような設計は、一部のシナリオ (ワイヤレス ネットワークでのマルチキャストの使用など) やノードが信頼できない場合 (パブリック アクセス ネットワークなど) では非効率となる可能性があります。これらのセキュリティと運用の問題、および関連する緩和ソリューションは 20 を超える RFC で文書化されています。これらの問題と解決策を単一の文書で追跡する必要があります。
To that aim, this document summarizes the published ND issues and then describes how all these issues originate from three causes. Addressing the issues is made simpler by addressing the causes. This document also analyzes the mitigation solutions and demonstrates that isolating hosts into different subnets and links can help to address the three causes. Guidance is provided for selecting a suitable isolation method to prevent potential ND issues.
その目的を達成するために、このドキュメントでは公開されている ND 問題を要約し、これらすべての問題が 3 つの原因からどのように発生するのかについて説明します。原因に対処することで、問題への対処が簡単になります。このドキュメントでは、緩和ソリューションも分析し、ホストを異なるサブネットとリンクに分離することが 3 つの原因の解決に役立つことを示します。潜在的な ND 問題を防ぐために、適切な分離方法を選択するためのガイダンスが提供されます。
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書は Internet Standards Track 仕様ではありません。情報提供を目的として公開されています。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9898.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9898 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Terminology
2. Review of Inventoried ND Issues
2.1. Multicast May Cause Performance and Reliability Issues
2.2. Trusting-All-Nodes May Cause On-Link Security Issues
2.3. Router-NCE-on-Demand May Cause Forwarding Delay, NCE
Exhaustion, and Address Accountability Issues
2.4. Summary of ND Issues
3. Review of ND Mitigation Solutions
3.1. Mobile Broadband IPv6 (MBBv6)
3.2. Fixed Broadband IPv6 (FBBv6)
3.3. Unique Prefix per Host (UPPH)
3.4. Wireless ND (WiND)
3.5. Scalable Address Resolution Protocol (SARP)
3.6. ND Optimization for TRILL
3.7. Proxy ND in Ethernet Virtual Private Networks (ND EVPN)
3.8. Reducing Router Advertisements per RFC 7772
3.9. Gratuitous Neighbor Discovery (GRAND)
3.10. Source Address Validation Improvement (SAVI) and Router
Advertisement Guard (RA-Guard)
3.11. Dealing with NCE Exhaustion Attacks per RFC 6583
3.12. Registering Self-Generated IPv6 Addresses Using DHCPv6 per
RFC 9686
3.13. Enhanced DAD
3.14. ND Mediation for IP Interworking of Layer 2 VPNs
3.15. ND Solutions Defined Before the Latest Versions of ND
3.15.1. Secure Neighbor Discovery (SEND)
3.15.2. Cryptographically Generated Addresses (CGA)
3.15.3. ND Proxy
3.15.4. Optimistic DAD
4. Guidelines for Prevention of Potential ND Issues
4.1. Learning Host Isolation from the Existing Solutions
4.2. Applicability of Various Isolation Methods
4.2.1. Applicability of L3+L2 Isolation
4.2.2. Applicability of L3 Isolation
4.2.3. Applicability of Partial L2 Isolation
4.3. Guidelines for Applying Isolation Methods
5. Security Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Authors' Addresses
Neighbor Discovery (ND) [RFC4861] specifies the mechanisms that IPv6 nodes (hosts and routers) on the same link use to communicate and learn about each other. Stateless Address Autoconfiguration (SLAAC) [RFC4862] builds on those ND mechanisms to let nodes configure their own IPv6 addresses. When analyzing the issues nodes may encounter with ND, it helps to view the ND messages they exchange throughout their life cycle, taking SLAAC into consideration.
近隣探索 (ND) [RFC4861] は、同じリンク上の IPv6 ノード (ホストとルーター) が通信し、相互について学習するために使用するメカニズムを指定します。ステートレス アドレス自動構成 (SLAAC) [RFC4862] は、ノードが独自の IPv6 アドレスを構成できるように、これらの ND メカニズムに基づいて構築されています。ノードが ND で発生する可能性のある問題を分析する場合、SLAAC を考慮して、ノードがライフサイクル全体で交換する ND メッセージを確認することが役立ちます。
For a host, the overall procedure is as follows:
ホストの場合、全体的な手順は次のとおりです。
1. LLA DAD: The host forms a Link-Local Address (LLA) and performs Duplicate Address Detection (DAD) using multicast Neighbor Solicitations (NSs).
1. LLA DAD: ホストはリンクローカル アドレス (LLA) を形成し、マルチキャスト近隣要請 (NS) を使用して重複アドレス検出 (DAD) を実行します。
2. Router discovery: The host sends multicast Router Solicitations (RSs) to discover a router on the link. The router responds with Router Advertisements (RAs), providing subnet prefixes and other information. The host installs a Neighbor Cache Entry (NCE) for that router upon receiving the RAs. In contrast, the router cannot install an NCE for the host at this moment of the exchange because the host's global IP address is still unknown. When the router later needs to forward a packet to the host's global address, it will perform address resolution and install an NCE for the host.
2. ルーターの検出: ホストはマルチキャスト ルーター要請 (RS) を送信して、リンク上のルーターを検出します。ルーターはルーター アドバタイズメント (RA) で応答し、サブネット プレフィックスやその他の情報を提供します。ホストは、RA を受信すると、そのルータの近隣キャッシュ エントリ（NCE）をインストールします。対照的に、ホストのグローバル IP アドレスがまだ不明であるため、ルータは交換のこの時点ではホストに NCE をインストールできません。ルータは後でパケットをホストのグローバル アドレスに転送する必要がある場合、アドレス解決を実行し、ホストの NCE をインストールします。
3. GUA DAD: The host forms a Global Unicast Address (GUA) [RFC3587] or a Unique Local Address (ULA) [RFC4193] and uses multicast NSs for DAD. For simplicity of description, this document will not further distinguish GUA and ULA.
3. GUA DAD: ホストは、グローバル ユニキャスト アドレス (GUA) [RFC3587] またはユニーク ローカル アドレス (ULA) [RFC4193] を形成し、DAD にマルチキャスト NS を使用します。説明を簡単にするため、この文書では GUA と ULA をさらに区別しません。
4. Next-hop determination and address resolution: When the host needs to send a packet, it will first determine whether the next hop is a router or an on-link host (which is the destination). If the next hop is a router, the host already has the NCE for that router. If the next hop is an on-link host, it will use multicast NSs to perform address resolution for the destination host. As a result, the source host installs an NCE for the destination host.
4. ネクスト ホップの決定とアドレス解決: ホストがパケットを送信する必要がある場合、ホストはまずネクスト ホップがルーターであるかオンリンク ホスト (宛先) であるかを判断します。ネクスト ホップがルータの場合、ホストはすでにそのルータの NCE を持っています。ネクスト ホップがオンリンク ホストの場合、マルチキャスト NS を使用して宛先ホストのアドレス解決を実行します。その結果、ソース ホストは宛先ホストの NCE をインストールします。
5. Node Unreachability Detection (NUD): The host uses unicast NSs to determine whether another node with an NCE is still reachable.
5. ノード到達不能検出 (NUD): ホストはユニキャスト NS を使用して、NCE を持つ別のノードがまだ到達可能かどうかを判断します。
6. Link-layer address change announcement: If a host's link-layer address changes, it may use multicast Neighbor Advertisements (NAs) to announce its new link-layer address to other nodes.
6. リンク層アドレス変更のアナウンスメント: ホストのリンク層アドレスが変更された場合、ホストはマルチキャスト近隣通知 (NA) を使用して、新しいリンク層アドレスを他のノードにアナウンスすることがあります。
For a router, the procedure is similar except that there is no router discovery. Instead, routers perform a Redirect procedure that hosts do not have. A router sends a Redirect to inform a node of a better next hop for the node's traffic.
ルーターの場合も、ルーターの検出がない点を除けば、手順は同様です。代わりに、ルーターはホストにはないリダイレクト手順を実行します。ルーターはリダイレクトを送信して、ノードのトラフィックに適したネクスト ホップをノードに通知します。
ND uses multicast in many messages and trusts messages from all nodes; in addition, routers may install NCEs for hosts on demand when they are to forward packets to these hosts. These may lead to issues. Concretely, various ND issues and mitigation solutions have been published in more than 20 RFCs, including:
ND は多くのメッセージでマルチキャストを使用し、すべてのノードからのメッセージを信頼します。さらに、ルータは、パケットをホストに転送するときに、オンデマンドでホスト用の NCE をインストールする場合があります。これらは問題を引き起こす可能性があります。具体的には、次のようなさまざまな ND の問題と緩和ソリューションが 20 以上の RFC で公開されています。
* "IPv6 Neighbor Discovery (ND) Trust Models and Threats" [RFC3756]
* 「IPv6 近隣探索 (ND) 信頼モデルと脅威」 [RFC3756]
* "SEcure Neighbor Discovery (SEND)" [RFC3971]
* 「安全な近隣探索 (SEND)」[RFC3971]
* "Cryptographically Generated Addresses (CGA)" [RFC3972]
* 「暗号的に生成されたアドレス (CGA)」[RFC3972]
* "Neighbor Discovery Proxies (ND Proxy)" [RFC4389]
* 「近隣探索プロキシ (ND プロキシ)」 [RFC4389]
* "Optimistic Duplicate Address Detection (DAD) for IPv6" [RFC4429]
* 「IPv6 の楽観的重複アドレス検出 (DAD)」[RFC4429]
* "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)" [RFC6459]
* 「第 3 世代パートナーシップ プロジェクト (3GPP) 進化型パケット システム (EPS) における IPv6」[RFC6459]
* "IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts" [RFC7066]
* 「第 3 世代パートナーシップ プロジェクト (3GPP) セルラー ホスト用の IPv6」[RFC7066]
* "IPv6 in the context of TR-101" [TR177]
* 「TR-101 のコンテキストにおける IPv6」 [TR177]
* "Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs" [RFC6575]
* 「レイヤー 2 VPN の IP インターワーキングのためのアドレス解決プロトコル (ARP) 仲介」 [RFC6575]
* "Operational Neighbor Discovery Problems" [RFC6583]
* 「運用上の近隣探索の問題」 [RFC6583]
* "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775]
* 「低電力無線パーソナル エリア ネットワーク (6LoWPAN) 上の IPv6 の近隣探索の最適化」 [RFC6775]
* "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery" [RFC8505]
* 「低電力無線パーソナル エリア ネットワーク (6LoWPAN) 近隣探索を介した IPv6 の登録拡張」 [RFC8505]
* "Address-Protected Neighbor Discovery for Low-Power and Lossy Networks" [RFC8928]
* 「低電力および損失の多いネットワークのためのアドレス保護された近隣探索」 [RFC8928]
* "IPv6 Backbone Router" [RFC8929]
* 「IPv6 バックボーンルーター」[RFC8929]
* "Architecture and Framework for IPv6 over Non-Broadcast Access" [SND]
* 「非ブロードキャスト アクセスを介した IPv6 のアーキテクチャとフレームワーク」[SND]
* "Duplicate Address Detection Proxy" [RFC6957]
* 「重複アドレス検出プロキシ」[RFC6957]
* "Source Address Validation Improvement (SAVI) Framework" [RFC7039]
* 「送信元アドレス検証改善 (SAVI) フレームワーク」 [RFC7039]
* "IPv6 Router Advertisement Guard" [RFC6105]
* 「IPv6ルーターアドバタイズメントガード」[RFC6105]
* "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)" [RFC7113]
* 「IPv6 ルーターアドバタイズメントガード (RA-Guard) の実装アドバイス」 [RFC7113]
* "Enhanced Duplicate Address Detection" [RFC7527]
* 「拡張重複アドレス検出」[RFC7527]
* "The Scalable Address Resolution Protocol (SARP) for Large Data Centers" [RFC7586]
* 「大規模データセンター向けのスケーラブル アドレス解決プロトコル (SARP)」[RFC7586]
* "Reducing Energy Consumption of Router Advertisements" [RFC7772]
* 「ルーター広告のエネルギー消費の削減」[RFC7772]
* "Unique IPv6 Prefix per Host" [RFC8273]
* 「ホストごとの一意の IPv6 プレフィックス」 [RFC8273]
* "Transparent Interconnection of Lots of Links (TRILL): ARP and Neighbor Discovery (ND) Optimization" [RFC8302]
* 「多数のリンクの透過的相互接続 (TRILL): ARP および近隣探索 (ND) の最適化」 [RFC8302]
* "Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers" [RFC9131]
* 「無償近隣探索: ファーストホップルーターでの近隣キャッシュエントリの作成」 [RFC9131]
* "Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Networks" [RFC9161]
* 「イーサネット仮想プライベートネットワークにおけるプロキシ ARP/ND の運用面」 [RFC9161]
* "Using DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique IPv6 Prefixes per Client in Large Broadcast Networks" [RFC9663]
* 「DHCPv6 プレフィックス委任 (DHCPv6-PD) を使用して、大規模なブロードキャスト ネットワークでクライアントごとに一意の IPv6 プレフィックスを割り当てる」 [RFC9663]
This document summarizes these RFCs into a one-stop reference (as of the time of writing) for easier access. This document also identifies three causes of the issues and defines three host isolation methods to address the causes and prevent potential ND issues.
この文書は、アクセスしやすいように、これらの RFC をワンストップのリファレンスにまとめています (執筆時点)。このドキュメントでは、問題の 3 つの原因も特定し、原因に対処して潜在的な ND 問題を防ぐための 3 つのホスト分離方法を定義します。
This document uses the terms defined in [RFC4861]. Additional terms are defined in this section.
この文書では、[RFC4861] で定義されている用語を使用します。このセクションでは追加の用語を定義します。
MAC:
MAC:
Media Access Control. To avoid confusion with link-local addresses, link-layer addresses are referred to as "MAC addresses" in this document.
メディアアクセス制御。リンクローカル アドレスとの混同を避けるため、このドキュメントではリンク層アドレスを「MAC アドレス」と呼びます。
Host Isolation:
ホストの分離:
Separating hosts into different subnets or links.
ホストを異なるサブネットまたはリンクに分離します。
L3 Isolation:
L3 分離:
Allocating a Unique Prefix per Host (UPPH) [RFC8273] [RFC9663] so that every host is in a different subnet. Given that a unique prefix can be allocated per host on shared media, hosts in different subnets may be on the same link.
すべてのホストが異なるサブネットに存在するように、ホストごとに一意のプレフィックスを割り当てる (UPPH) [RFC8273] [RFC9663]。共有メディア上のホストごとに一意のプレフィックスを割り当てることができるため、異なるサブネット内のホストが同じリンク上に存在する可能性があります。
L2 Isolation:
L2分離:
Taking measures to prevent a host from reaching other hosts directly in Layer 2 (L2) so that every host is in a different link. Due to the existence of Multi-Link Subnet [RFC4903], hosts in different links may be in the same subnet. Therefore, L2 Isolation does not imply L3 Isolation, and L3 Isolation does not imply L2 Isolation either.
ホストがレイヤ 2 (L2) 内の他のホストに直接到達できないようにするための措置を講じ、すべてのホストが異なるリンクに存在するようにします。マルチリンク サブネット [RFC4903] の存在により、異なるリンクのホストが同じサブネット内に存在する可能性があります。したがって、L2 分離は L3 分離を意味せず、L3 分離は L2 分離も意味しません。
L3+L2 Isolation:
L3+L2分離:
Applying L3 Isolation and L2 Isolation simultaneously so that every host is in a different subnet and on a different link.
L3 分離と L2 分離を同時に適用して、すべてのホストが異なるサブネットおよび異なるリンク上に存在するようにします。
Partial L2 Isolation:
部分的な L2 分離:
Using an L3 ND Proxy [RFC4389] device to represent the hosts behind it to other hosts in the same subnet. Within the subnet, ND multicast exchange is segmented into multiple smaller scopes, each represented by an ND Proxy device.
L3 ND プロキシ [RFC4389] デバイスを使用して、その背後にあるホストを同じサブネット内の他のホストに表します。サブネット内では、ND マルチキャスト交換は複数の小さなスコープに分割され、それぞれが ND プロキシ デバイスによって表されます。
In some cases, ND uses multicast for NSs, NAs, RSs, and RAs. While multicast can be highly efficient in certain scenarios (e.g., in wired networks), multicast can also be inefficient in other scenarios (e.g., in large L2 networks or wireless networks).
場合によっては、ND は NS、NA、RS、および RA にマルチキャストを使用します。マルチキャストは特定のシナリオ (有線ネットワークなど) では非常に効率的ですが、他のシナリオ (大規模な L2 ネットワークや無線ネットワークなど) では非効率になる場合もあります。
Typically, multicast can create a large amount of protocol traffic in large L2 networks. This can consume network bandwidth, increase processing overhead, and degrade network performance [RFC7342].
通常、マルチキャストは大規模な L2 ネットワークで大量のプロトコル トラフィックを作成する可能性があります。これにより、ネットワーク帯域幅が消費され、処理オーバーヘッドが増加し、ネットワーク パフォーマンスが低下する可能性があります [RFC7342]。
In wireless networks, multicast can be inefficient or even unreliable due to a higher probability of transmission interference, lower data rate, and lack of acknowledgements (Section 3.1 of [RFC9119]).
無線ネットワークでは、送信干渉の可能性が高く、データレートが低く、確認応答が欠如しているため、マルチキャストは非効率的であったり、信頼性が低くなったりする可能性があります ([RFC9119] のセクション 3.1)。
Multicast-related performance issues of the various ND messages are summarized below:
さまざまな ND メッセージのマルチキャスト関連のパフォーマンスの問題を以下にまとめます。
* Issue 1: LLA DAD degrades performance
* 問題 1: LLA DAD によるパフォーマンスの低下
In an L2 network of N addresses (which can be much larger than the number of hosts, as each host can have multiple addresses), there can be N such multicast messages. This may cause performance issues when N is large.
N 個のアドレスを持つ L2 ネットワーク (各ホストは複数のアドレスを持つことができるため、ホストの数よりもはるかに大きくなる可能性があります) では、このようなマルチキャスト メッセージが N 個存在する可能性があります。N が大きい場合、これによりパフォーマンスの問題が発生する可能性があります。
* Issue 2: Router's periodic unsolicited RAs drain host's battery
* 問題 2: ルーターの定期的な一方的な RA により、ホストのバッテリーが消耗します。
Multicast RAs are generally limited to one packet every MIN_DELAY_BETWEEN_RAS (3 seconds), and there are usually only one or two routers on the link, so it is unlikely to cause a performance issue. However, for battery-powered hosts, such messages may wake them up and drain their batteries [RFC7772].
マルチキャスト RA は通常、MIN_DELAY_BETWEEN_RAS (3 秒) ごとに 1 つのパケットに制限されており、通常はリンク上にルーターが 1 つまたは 2 つしかないため、パフォーマンスの問題が発生する可能性はほとんどありません。ただし、バッテリ駆動のホストの場合、そのようなメッセージによってホストが目覚め、バッテリが消耗する可能性があります [RFC7772]。
* Issue 3: GUA DAD degrades performance
* 問題 3: GUA DAD によりパフォーマンスが低下する
This is the same as in Issue 1.
これは問題 1 と同じです。
* Issue 4: Router's address resolution for hosts degrades performance
* 問題 4: ルーターのホストのアドレス解決によりパフォーマンスが低下する
This is the same as in Issue 1.
これは問題 1 と同じです。
* Issue 5: Host's address resolution for hosts degrades performance
* 問題 5: ホストのアドレス解決によりパフォーマンスが低下する
This is the same as in Issue 1.
これは問題 1 と同じです。
* Issue for further study: Multicast NAs for host's MAC address changes may degrade performance
* 更なる検討課題: ホストの MAC アドレス変更に対するマルチキャスト NA によりパフォーマンスが低下する可能性がある
With randomized and changing MAC addresses [MADINAS], there may be many such multicast messages.
ランダム化され変化する MAC アドレス [MADINAS] では、そのようなマルチキャスト メッセージが多数存在する可能性があります。
In wireless networks, multicast is more likely to cause packet loss. Because DAD treats no response as no duplicate address detected, packet loss may cause duplicate addresses to be undetected. Multicast reliability issues are summarized below:
ワイヤレス ネットワークでは、マルチキャストによりパケット損失が発生する可能性が高くなります。DAD は応答がないことを重複アドレスが検出されなかったものとして扱うため、パケット損失により重複アドレスが検出されなくなる可能性があります。マルチキャストの信頼性の問題は以下にまとめられています。
* Issue 6: LLA DAD not completely reliable in wireless networks
* 問題 6: LLA DAD はワイヤレス ネットワークでは完全には信頼できません
* Issue 7: GUA DAD not completely reliable in wireless networks
* 問題 7: GUA DAD はワイヤレス ネットワークでは完全には信頼できません
Note: IPv6 address collisions are extremely unlikely. As a result, these two issues are largely theoretical rather than practical.
注: IPv6 アドレスの衝突は非常にまれです。結果として、これら 2 つの問題は、実際的な問題というよりも、主に理論的な問題になります。
In scenarios such as public access networks, some nodes may not be trustworthy. An attacker on the link can cause the following on-link security issues [RFC3756] [RFC9099]:
パブリック アクセス ネットワークなどのシナリオでは、一部のノードが信頼できない場合があります。リンク上の攻撃者は、次のリンク上のセキュリティ問題を引き起こす可能性があります [RFC3756] [RFC9099]:
* Issue 8: Source IP address spoofing
* 問題 8: 送信元 IP アドレスのスプーフィング
An attacker can use another node's IP address as the source address of its ND message to pretend to be that node. The attacker can then launch various Redirect or Denial-of-Service (DoS) attacks.
攻撃者は、別のノードの IP アドレスを ND メッセージの送信元アドレスとして使用して、そのノードになりすますことができます。その後、攻撃者はさまざまなリダイレクト攻撃やサービス拒否 (DoS) 攻撃を開始する可能性があります。
* Issue 9: Denial of DAD
* 問題 9: DAD の否定
An attacker can repeatedly reply to a victim's DAD messages, causing the victim's address configuration procedure to fail, resulting in a DoS to the victim.
攻撃者は被害者の DAD メッセージに繰り返し返信することで、被害者のアドレス構成手順が失敗し、被害者に DoS が発生する可能性があります。
* Issue 10: Rogue RAs
* 問題 10: 不正な RA
An attacker can send RAs to victim hosts to pretend to be a router. The attacker can then launch various Redirect or DoS attacks.
攻撃者は、ルーターのふりをするために被害ホストに RA を送信することができます。その後、攻撃者はさまざまなリダイレクト攻撃や DoS 攻撃を開始する可能性があります。
* Issue 11: Spoofed redirects
* 問題 11: なりすましのリダイレクト
An attacker can send forged Redirects to victim hosts to redirect their traffic to the legitimate router itself.
攻撃者は、偽のリダイレクトを被害ホストに送信し、そのトラフィックを正規のルーター自体にリダイレクトする可能性があります。
* Issue 12: Replay attacks
* 問題 12: リプレイ攻撃
An attacker can capture valid ND messages and replay them later.
攻撃者は有効な ND メッセージをキャプチャし、後でそれらを再生する可能性があります。
When a router needs to forward a packet to a node but does not yet have a Neighbor-Cache Entry (NCE) for that node, it first creates an NCE in the INCOMPLETE state. The router then multicasts an NS to the node's solicited-node multicast address. When the destination replies with an NA containing its MAC address, the router updates the NCE with that address and changes its state to REACHABLE, thereby completing the entry. This process is referred to as "Router-NCE-on-Demand" in this document.
ルータがパケットをノードに転送する必要があるが、そのノードの近隣キャッシュ エントリ (NCE) をまだ持っていない場合、ルータはまず INCOMPLETE 状態の NCE を作成します。次に、ルーターは NS をノードの要請ノード マルチキャスト アドレスにマルチキャストします。宛先が MAC アドレスを含む NA で応答すると、ルータはそのアドレスで NCE を更新し、状態を REACHABLE に変更して、エントリを完了します。このプロセスは、このドキュメントでは「Router-NCE-on-Demand」と呼ばれます。
Router-NCE-on-Demand can cause the following issues:
Router-NCE-on-Demand により、次の問題が発生する可能性があります。
* Issue 13: NCE exhaustion
* 問題 13: NCE の枯渇
An attacker can send a high volume of packets targeting non-existent IP addresses, causing the router to create numerous NCEs in the INCOMPLETE state. The resulting resource exhaustion may cause the router to malfunction. This vulnerability, described as "NCE exhaustion" in this document, does not require the attacker to be on-link.
攻撃者は、存在しない IP アドレスをターゲットとする大量のパケットを送信し、ルータに INCOMPLETE 状態の NCE を多数作成させる可能性があります。結果としてリソースが枯渇すると、ルーターが誤動作する可能性があります。この文書では「NCE 枯渇」として説明されているこの脆弱性は、攻撃者がオンリンクである必要はありません。
* Issue 14: Router forwarding delay
* 問題 14: ルーター転送の遅延
When a packet arrives at a router, the router buffers it while attempting to determine the host's MAC address. This buffering delays forwarding and, depending on the router's buffer size, may lead to packet loss. This delay is referred to as "Router-NCE-on-Demand forwarding delay" in this document.
パケットがルーターに到着すると、ルーターはホストの MAC アドレスを特定しようとする間、パケットをバッファリングします。このバッファリングにより転送が遅延し、ルーターのバッファ サイズによってはパケット損失が発生する可能性があります。この遅延は、この文書では「Router-NCE-on-Demand 転送遅延」と呼ばれます。
* Issue 15: Lack of address accountability
* 問題 15: アドレスに対する説明責任の欠如
With SLAAC, hosts generate their IP addresses. The router does not become aware of a host's IP address until an NCE entry is created. With DHCPv6 [RFC8415], the router may not know the host's addresses unless it performs DHCPv6 snooping. In public access networks, where subscriber management often relies on IP address (or prefix) identification, this lack of address accountability poses a challenge [AddrAcc]. Without knowledge of the host's IP address, network administrators are unable to effectively manage subscribers, which is particularly problematic in public access networks. Moreover, once a router has created its NCEs, ND [RFC4861] provides no mechanism to retrieve them for management or monitoring, as noted in Section 2.6.1 of [RFC9099].
SLAAC を使用すると、ホストは IP アドレスを生成します。ルータは、NCE エントリが作成されるまでホストの IP アドレスを認識しません。DHCPv6 [RFC8415] では、ルーターは DHCPv6 スヌーピングを実行しない限り、ホストのアドレスを認識できない可能性があります。加入者管理が IP アドレス (またはプレフィックス) の識別に依存することが多いパブリック アクセス ネットワークでは、このアドレス責任の欠如が課題を引き起こします [AddrAcc]。ホストの IP アドレスがわからないと、ネットワーク管理者は加入者を効果的に管理できません。これは、パブリック アクセス ネットワークで特に問題となります。さらに、[RFC9099] のセクション 2.6.1 に記載されているように、ルーターが NCE を作成すると、ND [RFC4861] は管理または監視のために NCE を取得するメカニズムを提供しません。
The ND issues, as discussed in Sections 2.1, 2.2, and 2.3, are summarized below. These issues stem from three primary causes: multicast, Trusting-all-nodes, and Router-NCE-on-Demand. Eliminating any of these causes would also mitigate the corresponding issues. These observations provide guidance for addressing and preventing ND-related issues.
セクション 2.1、2.2、および 2.3 で説明した ND の問題を以下に要約します。これらの問題は、マルチキャスト、全ノードの信頼、およびルータ NCE オンデマンドの 3 つの主な原因から発生します。これらの原因のいずれかを排除すると、対応する問題も軽減されます。これらの観察結果は、ND 関連の問題に対処し、防止するための指針を提供します。
1. Multicast-related issues:
1. マルチキャスト関連の問題:
* Performance issues:
* パフォーマンスの問題:
- Issue 1: LLA DAD degrades performance
- 問題 1: LLA DAD によるパフォーマンスの低下
- Issue 2: Router's periodic unsolicited RAs drain host's battery
- 問題 2: ルーターの定期的な一方的な RA により、ホストのバッテリーが消耗します。
- Issue 3: GUA DAD degrades performance
- 問題 3: GUA DAD によりパフォーマンスが低下する
- Issue 4: Router's address resolution for hosts degrades performance
- 問題 4: ルーターのホストのアドレス解決によりパフォーマンスが低下する
- Issue 5: Host's address resolution for hosts degrades performance
- 問題 5: ホストのアドレス解決によりパフォーマンスが低下する
* Reliability issues:
* 信頼性の問題:
- Issue 6: LLA DAD not completely reliable in wireless networks
- 問題 6: LLA DAD はワイヤレス ネットワークでは完全には信頼できません
- Issue 7: GUA DAD not completely reliable in wireless networks
- 問題 7: GUA DAD はワイヤレス ネットワークでは完全には信頼できません
2. Trusting-all-nodes related issues:
2. 全ノードの信頼に関する問題:
* Issue 8: Source IP address spoofing
* 問題 8: 送信元 IP アドレスのスプーフィング
* Issue 9: Denial of DAD
* 問題 9: DAD の否定
* Issue 10: Rogue RAs
* 問題 10: 不正な RA
* Issue 11: Spoofed redirects
* 問題 11: なりすましのリダイレクト
* Issue 12: Replay attacks
* 問題 12: リプレイ攻撃
3. Router-NCE-on-Demand related issues:
3. ルーター NCE オンデマンド関連の問題:
* Issue 13: NCE exhaustion
* 問題 13: NCE の枯渇
* Issue 14: Router forwarding delay
* 問題 14: ルーター転送の遅延
* Issue 15: Lack of address accountability
* 問題 15: アドレスに対する説明責任の欠如
These issues are potential vulnerabilities and may not manifest in all usage scenarios.
これらの問題は潜在的な脆弱性であり、すべての使用シナリオで現れるとは限りません。
When these issues may occur in a specific deployment, it is advisable to consider the mitigation solutions available. They are described in the following section.
特定の展開でこれらの問題が発生する可能性がある場合は、利用可能な緩和ソリューションを検討することをお勧めします。それらについては次のセクションで説明します。
Table 1 summarizes ND mitigation solutions available for Issues 1-15 described in Section 2.4. Similar solutions are grouped, beginning with those that address the most issues. Unrelated solutions are ordered based on the issues (listed in Section 2.4) they address. Each solution in the table will be explained in a sub-section later, where abbreviations in the table are described.
表 1 は、セクション 2.4 で説明されている問題 1 ～ 15 に対して利用可能な ND 軽減ソリューションをまとめたものです。同様のソリューションは、最も多くの問題に対処するものから順にグループ化されています。関連のないソリューションは、対処する問題 (セクション 2.4 にリストされている) に基づいて順序付けされます。表内の各解決策については、後のサブセクションで説明し、表内の略語について説明します。
In Table 1, a letter code indicates the RFC category of the mitigation solution (see BCP 9 [RFC2026] for an explanation of these categories):
表 1 では、文字コードは緩和ソリューションの RFC カテゴリを示しています (これらのカテゴリの説明については、BCP 9 [RFC2026] を参照してください)。
S:
S:
Standards Track (Proposed Standard or Internet Standard)
標準化トラック (提案された標準またはインターネット標準)
E:
E:
Experimental
実験的
I:
私：
Informational
情報提供
B:
B:
Best Current Practice
現在のベストプラクティス
N/A:
該当なし:
Not Applicable (not an RFC)
該当なし (RFC ではない)
The abbreviations in Table 1 correspond to Section 2.4 as follows:
表 1 の略語は、次のようにセクション 2.4 に対応します。
On-link sec.:
オンリンク秒:
Trusting-all-nodes related issues
全ノードの信頼に関する問題
NCE exh.:
NCE 例:
NCE exhaustion
NCE疲労
Fwd. delay:
前進。遅れ：
Router forwarding delay
ルーター転送遅延
No addr. acc.:
アドレスがありません。参照:
Lack of address accountability
アドレス責任の欠如
+==========+====+===========+=======+=========+====+=======+=======+
| ND |RFC |Multicast |Reliabi| On-link |NCE | Fwd. | No |
| solution |cat.|performance|lity | sec. |exh.| delay | addr. |
| | | | | | | | acc. |
| | +===+=+=+=+=+=====+=+=========+====+=======+=======+
| | | 1 |2|3|4|5| 6 |7| 8-12 | 13 | 14 | 15 |
+==========+====+===+=+=+=+=+=====+=+=========+====+=======+=======+
| MBBv6 | I | All identified issues solved |
+----------+----+--------------------------------------------------+
| FBBv6 |N/A | All identified issues solved |
+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
| UPPH | I | |X| |X|X| |X| | X | X | X |
+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
| WiND | S |All issues solved for Low-Power and Lossy Networks|
| | | (LLNs) |
+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
| SARP | E | | | | |X| | | | | | |
+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
| ND TRILL | S | | | | |X| | | | | | |
+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
| ND EVPN | S | | | | |X| | | | | | |
+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
| RFC 7772 | B | |X| | | | | | | | | |
+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
| GRAND | S | | | |X| | | | | | X | |
+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
| SAVI/ | I | | | | | | | | X | | | |
| RA-G | | | | | | | | | | | | |
+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
| RFC 6583 | I | | | | | | | | | X | | |
+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
| RFC 9686 | S | | | | | | | | | | | X |
+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
Table 1: Solutions for Identified Issues
表 1: 特定された問題の解決策
The IPv6 solution defined in "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)" [RFC6459], "IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts" [RFC7066], and "Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link" [RFC7278] is called Mobile Broadband IPv6 (MBBv6) in this document. They are Informational RFCs. The key points are:
「第 3 世代パートナーシップ プロジェクト (3GPP) 進化型パケット システム (EPS) における IPv6」[RFC6459]、「第三世代パートナーシップ プロジェクト (3GPP) セルラー ホストの IPv6」[RFC7066]、および「第三世代パートナーシップ プロジェクト (3GPP) モバイル インターフェイスから LAN リンクへの IPv6 /64 プレフィックスの拡張」[RFC7278] で定義されている IPv6 ソリューションは、モバイルと呼ばれます。このドキュメントではブロードバンド IPv6 (MBBv6) について説明します。これらは情報提供用の RFC です。重要なポイントは次のとおりです。
* Putting every host (e.g., the mobile User Equipment (UE)) in a Point-to-Point (P2P) link with the router (e.g., the mobile gateway) has the following outcomes:
* すべてのホスト (例: モバイル ユーザー機器 (UE)) をルーター (例: モバイル ゲートウェイ) とのポイントツーポイント (P2P) リンクに置くと、次の結果が得られます。
- All multicast is effectively turned into unicast.
- すべてのマルチキャストは事実上ユニキャストに変換されます。
- The P2P links do not have a MAC address. Therefore, Router-NCE-on-Demand is not needed.
- P2P リンクには MAC アドレスがありません。したがって、Router-NCE-on-Demand は必要ありません。
- Trusting-all-nodes is only relevant to the router. By applying filtering at the router (e.g., dropping RAs from the hosts), even malicious hosts cannot cause harm.
- すべてのノードを信頼することはルーターにのみ関係します。ルーターでフィルタリングを適用する（ホストから RA をドロップするなど）ことにより、悪意のあるホストであっても害を及ぼすことはできません。
* Assigning a unique /64 prefix to each host. Together with the P2P link, this puts each host on a separate link and subnet.
* 各ホストに一意の /64 プレフィックスを割り当てます。P2P リンクと組み合わせると、各ホストが個別のリンクとサブネット上に配置されます。
* Maintaining (prefix, interface) binding at the router for forwarding purposes.
* 転送目的でルーターでの (プレフィックス、インターフェイス) バインディングを維持します。
Since all the three causes of ND issues are addressed, all the issues discussed in Section 2.4 are addressed.
ND 問題の 3 つの原因がすべて解決されているため、セクション 2.4 で説明されているすべての問題が解決されています。
The IPv6 solution defined in "IPv6 in the context of TR-101" [TR177] is called Fixed Broadband IPv6 (FBBv6) in this document. FBBv6 has two flavors:
「TR-101 のコンテキストにおける IPv6」[TR177] で定義されている IPv6 ソリューションを、この文書では固定ブロードバンド IPv6 (FBBv6) と呼びます。FBBv6 には 2 つの種類があります。
* P2P: Every host (e.g., the Residential Gateway (RG)) is in a P2P link with the router (e.g., the Broadband Network Gateway (BNG)). In this case, the solution is functionally similar to MBBv6. All ND issues discussed in Section 2.4 are solved.
* P2P: すべてのホスト (レジデンシャル ゲートウェイ (RG) など) はルーター (ブロードバンド ネットワーク ゲートウェイ (BNG) など) と P2P リンクにあります。この場合、ソリューションは機能的に MBBv6 と同様です。セクション 2.4 で説明した ND の問題はすべて解決されています。
* Point to Multipoint (P2MP): All hosts (e.g., the RGs) connected to an access device (e.g., the Optical Line Terminal (OLT)) are in a P2MP link with the router (e.g., the BNG). This is achieved by placing all hosts in a single VLAN on the router and configuring the OLT to block any frame from being forwarded between its access ports; traffic from each host can travel only up toward the router, not sideways to another host, thereby preventing direct host-to-host communication.
* ポイントツーマルチポイント（P2MP）：アクセスデバイス（光回線端末（OLT）など）に接続されているすべてのホスト（RGなど）は、ルータ（BNGなど）とのP2MPリンク内にあります。これは、すべてのホストをルータ上の単一の VLAN に配置し、アクセス ポート間でフレームが転送されないように OLT を設定することによって実現されます。各ホストからのトラフィックはルーターに向かって上方向にのみ移動でき、別のホストに横方向には移動できないため、ホスト間の直接通信が妨げられます。
The following list summarizes the two key aspects of the FBBv6-P2MP architecture as described in [TR177] and the associated benefits:
次のリストは、[TR177] で説明されている FBBv6-P2MP アーキテクチャの 2 つの主要な側面と、それに関連する利点をまとめたものです。
* Implementing DAD proxy [RFC6957]:
* DAD プロキシの実装 [RFC6957]:
In a P2MP architecture described above, the normal ND DAD procedure will break down because hosts cannot exchange NSs with one another. To address this, the router participates in the DAD process as a DAD Proxy to resolve address duplication.
上で説明した P2MP アーキテクチャでは、ホストが相互に NS を交換できないため、通常の ND DAD プロシージャは機能しなくなります。これに対処するために、ルーターは DAD プロキシとして DAD プロセスに参加し、アドレスの重複を解決します。
The benefits are:
利点は次のとおりです。
- Multicast traffic from all hosts to the router is effectively converted into unicast, as hosts can only communicate directly with the router.
- ホストはルーターと直接通信することしかできないため、すべてのホストからルーターへのマルチキャスト トラフィックは効果的にユニキャストに変換されます。
- The Trusting-all-nodes model is limited to the router. By applying simple filtering (e.g., dropping RAs from hosts), the router can mitigate security risks, even from malicious hosts.
- 全ノード信頼モデルはルーターに限定されます。単純なフィルタリング (ホストから RA をドロップするなど) を適用することで、ルーターは悪意のあるホストからのセキュリティ リスクも軽減できます。
* Assigning a unique /64 prefix to each host:
* 各ホストに一意の /64 プレフィックスを割り当てる:
Assigning each host a unique /64 prefix results in several operational improvements:
各ホストに一意の /64 プレフィックスを割り当てると、運用上のいくつかの改善がもたらされます。
- The router can proactively install a forwarding entry for that prefix towards the host, eliminating the need for Router-NCE-on-Demand.
- ルータは、そのプレフィックスの転送エントリをホストに向けてプロアクティブにインストールできるため、Router-NCE-on-Demand の必要がなくなります。
- Since each host resides in a different subnet, traffic between hosts is routed through the router, eliminating the need for hosts to perform address resolution for one another.
- 各ホストは異なるサブネットに存在するため、ホスト間のトラフィックはルーター経由でルーティングされ、ホストが相互にアドレス解決を実行する必要がなくなります。
- Without address resolution, router multicast to hosts is limited to unsolicited RAs. As each host resides in its own subnet, these RAs are sent as unicast packets to individual hosts. This follows the approach specified in [RFC6085], where the host's MAC address replaces the multicast MAC address in the RA.
- アドレス解決がない場合、ホストへのルータのマルチキャストは、要求されていない RA に限定されます。各ホストは独自のサブネット内に存在するため、これらの RA はユニキャスト パケットとして個々のホストに送信されます。これは、[RFC6085] で指定されているアプローチに従っており、RA 内のマルチキャスト MAC アドレスがホストの MAC アドレスに置き換えられます。
Since all three causes of ND issues are addressed, all ND issues (Section 2.4) are also addressed.
ND 問題の 3 つの原因すべてが解決されるため、すべての ND 問題 (セクション 2.4) も解決されます。
Unique Prefix per Host (UPPH) solutions are described in [RFC8273] and [RFC9663]. Both are Informational RFCs. [RFC8273] relies on SLAAC for unique prefix allocation while [RFC9663] relies on DHCPv6 Prefix Delegation (DHCPv6-PD). That difference in allocation mechanism does not change the discussion on ND issues, because every IPv6 node is still required to run SLAAC, even when it receives its prefix via DHCPv6-PD. Therefore, discussing [RFC8273] alone is sufficient.
Unique Prefix per Host (UPPH) ソリューションは [RFC8273] および [RFC9663] で説明されています。どちらも情報 RFC です。[RFC8273] は一意のプレフィックス割り当てに SLAAC に依存しますが、[RFC9663] は DHCPv6 プレフィックス委任 (DHCPv6-PD) に依存します。この割り当てメカニズムの違いは、ND の問題に関する議論を変えるものではありません。すべての IPv6 ノードは、DHCPv6-PD 経由でプレフィックスを受信した場合でも、SLAAC を実行する必要があるからです。したがって、[RFC8273] だけを議論するだけで十分です。
[RFC8273] "improves host isolation and enhanced subscriber management on shared network segments" such as Wi-Fi or Ethernet. The key points are:
[RFC8273] は、Wi-Fi やイーサネットなどの「共有ネットワーク セグメント上のホスト分離を改善し、加入者管理を強化」します。重要なポイントは次のとおりです。
* When a prefix is allocated to the host, the router can proactively install a forwarding entry for that prefix towards the host. There is no more Router-NCE-on-Demand.
* プレフィックスがホストに割り当てられると、ルーターはそのプレフィックスの転送エントリをホストに向けてプロアクティブにインストールできます。Router-NCE-on-Demand はもうありません。
* Without address resolution, router multicast to hosts consists only of unsolicited RAs. They will be sent to hosts one by one in unicast because the prefix for every host is different.
* アドレス解決がなければ、ルータからホストへのマルチキャストは、要求されていない RA のみで構成されます。ホストごとにプレフィックスが異なるため、ホストに 1 つずつユニキャストで送信されます。
* Since different hosts are in different subnets, hosts will send traffic to other hosts via the router. There is no host-to-host address resolution.
* 異なるホストは異なるサブネットに存在するため、ホストはルーター経由で他のホストにトラフィックを送信します。ホスト間のアドレス解決はありません。
Therefore, ND issues caused by Router-NCE-on-Demand and router multicast to hosts are prevented.
したがって、Router-NCE-on-Demand およびホストへのルーター マルチキャストによって引き起こされる ND の問題が防止されます。
[RFC8273] indicates that a "network implementing a unique IPv6 prefix per host can simply ensure that devices cannot send packets to each other except through the first-hop router". However, when hosts are on a shared medium like Ethernet, ensuring "devices cannot send packets to each other except through the first-hop router" requires additional measures like Private VLAN [RFC5517]. Without such additional measures, on a shared medium, hosts can still reach each other in L2 as they belong to the same Solicited-Node Multicast Group. Therefore, Trusting-all-nodes and host multicast to routers may cause issues. Of the host multicast issues (i.e., Issues 1, 3, 5, 6, and 7), UPPH prevents Issues 5 and 7, because there is no need for address resolution among hosts (Issue 5), and there is no possibility of GUA duplication (Issue 7). However, Issues 1, 3, and 6 may occur.
[RFC8273] は、「ホストごとに一意の IPv6 プレフィックスを実装するネットワークは、デバイスがファーストホップ ルーターを経由しない限り相互にパケットを送信できないようにするだけでよい」と示しています。ただし、ホストがイーサネットなどの共有メディア上にある場合、「デバイスはファーストホップルーターを経由する場合を除いて相互にパケットを送信できない」ことを保証するには、プライベート VLAN [RFC5517] のような追加の対策が必要です。このような追加の手段を講じなくても、共有メディア上では、ホストは同じ要請ノード マルチキャスト グループに属しているため、引き続き L2 で相互に到達できます。したがって、すべてのノードを信頼し、ルーターへのホスト マルチキャストを行うと、問題が発生する可能性があります。ホスト マルチキャストの問題 (つまり、問題 1、3、5、6、および 7) のうち、UPPH は問題 5 と 7 を防止します。これは、ホスト間でアドレスを解決する必要がなく (問題 5)、GUA が重複する可能性がないため (問題 7) です。ただし、問題 1、3、および 6 が発生する可能性があります。
The term "Wireless ND (WiND)" is used in this document to describe the fundamentally different ND solution for Low-Power and Lossy Networks (LLNs) [RFC7102] that is defined in [RFC6775], [RFC8505], [RFC8928], and [RFC8929] (Standards Track). WiND changes host and router behaviors to use multicast only for router discovery. The key points are:
この文書では、「ワイヤレス ND (WiND)」という用語は、[RFC6775]、[RFC8505]、[RFC8928]、および [RFC8929] (Standards Track) で定義されている、低電力および損失の多いネットワーク (LLN) [RFC7102] 向けの根本的に異なる ND ソリューションを説明するために使用されます。WiND は、ルーターの検出にのみマルチキャストを使用するようにホストとルーターの動作を変更します。重要なポイントは次のとおりです。
* Hosts use unicast to proactively register their addresses at the routers. Routers use unicast to communicate with hosts and become an abstract registrar and arbitrator for address ownership.
* ホストはユニキャストを使用して、ルーターにアドレスを積極的に登録します。ルーターはユニキャストを使用してホストと通信し、アドレス所有権の抽象的なレジストラおよび調停者になります。
* The router also proactively installs NCEs for the hosts. This avoids the need for address resolution for the hosts.
* また、ルータはホストの NCE をプロアクティブにインストールします。これにより、ホストのアドレス解決が不要になります。
* The router sets the Prefix Information Option (PIO) L-bit to 0. Each host communicates only with the router (Section 6.3.4 of [RFC4861]).
* ルーターはプレフィックス情報オプション (PIO) の L ビットを 0 に設定します。各ホストはルーターとのみ通信します ([RFC4861] のセクション 6.3.4)。
* Other functionalities that are relevant only to LLNs.
* LLN にのみ関連するその他の機能。
WiND addresses all ND issues (Section 2.4) in LLNs. However, WiND support is not mandatory for general-purpose hosts. Therefore, it cannot be relied upon as a deployment option without imposing additional constraints on the participating nodes.
WiND は、LLN におけるすべての ND 問題 (セクション 2.4) に対処します。ただし、WiND サポートは汎用ホストには必須ではありません。したがって、参加しているノードに追加の制約を課すことなく、展開オプションとして利用することはできません。
The Scalable Address Resolution Protocol (SARP) [RFC7586] was an Experimental solution. That experiment ended in 2017, two years after the RFC was published. Because the idea has been used in mitigation solutions for more specific scenarios (described in Sections 3.6 and 3.7), it is worth describing here. The usage scenario is Data Centers (DCs), where large L2 domains span across multiple sites. In each site, multiple hosts are connected to a switch. The hosts can be Virtual Machines (VMs), so the number can be large. The switches are interconnected by a pure or overlay L2 network.
スケーラブル アドレス解決プロトコル (SARP) [RFC7586] は実験的なソリューションでした。この実験は、RFC が公開されてから 2 年後の 2017 年に終了しました。このアイデアは、より具体的なシナリオ (セクション 3.6 および 3.7 で説明) の緩和ソリューションで使用されているため、ここで説明する価値があります。使用シナリオは、大規模な L2 ドメインが複数のサイトにまたがるデータ センター (DC) です。各サイトでは、複数のホストがスイッチに接続されています。ホストは仮想マシン (VM) である場合があるため、その数は大きくなる可能性があります。スイッチは、純粋な L2 ネットワークまたはオーバーレイ L2 ネットワークによって相互接続されます。
The switch will snoop and install a (IP, MAC address) proxy table for the local hosts. The switch will also reply to address resolution requests from other sites to its hosts with its own MAC address. In doing so, all hosts within a site will appear to have a single MAC address to other sites. As such, a switch only needs to build a MAC address table for the local hosts and the remote switches, not for all the hosts in the L2 domain. Consequently, the MAC address table size of the switches is significantly reduced. A switch will also add the (IP, MAC address) replies from remote switches to its proxy ND table so that it can reply to future address resolution requests from local hosts for such IPs directly. This greatly reduces the number of address resolution multicast in the network.
スイッチはローカル ホストの (IP、MAC アドレス) プロキシ テーブルをスヌープしてインストールします。また、スイッチは、他のサイトからホストへのアドレス解決要求に対して、独自の MAC アドレスで応答します。そうすることで、サイト内のすべてのホストが他のサイトに対して単一の MAC アドレスを持っているように見えます。したがって、スイッチは、L2 ドメイン内のすべてのホストではなく、ローカル ホストとリモート スイッチの MAC アドレス テーブルを構築するだけで済みます。その結果、スイッチの MAC アドレス テーブルのサイズが大幅に削減されます。また、スイッチは、リモート スイッチからの (IP、MAC アドレス) 応答をプロキシ ND テーブルに追加し、そのような IP に対するローカル ホストからの今後のアドレス解決要求に直接応答できるようにします。これにより、ネットワーク内のアドレス解決マルチキャストの数が大幅に減少します。
Unlike MBBv6, FBBv6, and UPPH, which try to address all ND issues discussed in Section 2.4, SARP focuses on reducing address resolution multicast to improve the performance and scalability of large L2 domains in DCs.
セクション 2.4 で説明したすべての ND 問題に対処しようとする MBBv6、FBBv6、および UPPH とは異なり、SARP は、DC 内の大規模な L2 ドメインのパフォーマンスとスケーラビリティを向上させるために、アドレス解決マルチキャストを削減することに重点を置いています。
ARP and ND optimization for Transparent Interconnection of Lots of Links (TRILL) [RFC8302] (Standards Track) is similar to SARP (Section 3.5). It can be considered an application of SARP in the TRILL environment.
Transparent Interconnection of Lots of Links (TRILL) [RFC8302] (Standards Track) の ARP と ND の最適化は、SARP (セクション 3.5) に似ています。これは、TRILL 環境における SARP の応用と考えることができます。
Like SARP, ND optimization for TRILL focuses on reducing multicast address resolution. That is, it addresses Issue 5 (Section 2.1).
SARP と同様に、TRILL の ND 最適化は、マルチキャスト アドレス解決の削減に重点を置いています。つまり、問題 5 (セクション 2.1) に対処します。
Proxy ARP/ND in EVPN is specified in [RFC9161] (Standards Track). The usage scenario is DCs where large L2 domains span across multiple sites. In each site, multiple hosts are connected to a Provider Edge (PE) router. The PEs are interconnected by EVPN tunnels.
EVPN のプロキシ ARP/ND は [RFC9161] (標準化トラック) で規定されています。使用シナリオは、大規模な L2 ドメインが複数のサイトにまたがる DC です。各サイトでは、複数のホストがプロバイダー エッジ (PE) ルーターに接続されています。PE は EVPN トンネルによって相互接続されます。
The PE of each site snoops the local address resolution NAs to build (IP, MAC address) Proxy ND table entries. PEs then propagate such Proxy ND entries to other PEs via the Border Gateway Protocol (BGP). Each PE also snoops local hosts' address resolution NSs for remote hosts. If an entry exists in its Proxy ND table for the remote hosts, the PE will reply directly. Consequently, the number of multicast address resolution messages is significantly reduced.
各サイトの PE は、ローカル アドレス解決 NA をスヌープして、(IP、MAC アドレス) プロキシ ND テーブル エントリを構築します。次に、PE は、ボーダー ゲートウェイ プロトコル (BGP) を介して、そのようなプロキシ ND エントリを他の PE に伝播します。各 PE は、リモート ホストのローカル ホストのアドレス解決 NS もスヌープします。リモート ホストのプロキシ ND テーブルにエントリが存在する場合、PE は直接応答します。その結果、マルチキャスト アドレス解決メッセージの数が大幅に減少します。
Like SARP, Proxy ARP/ND in EVPN also focuses on reducing address resolution multicast.
SARP と同様に、EVPN のプロキシ ARP/ND もアドレス解決マルチキャストの削減に重点を置いています。
Maintaining IPv6 connectivity requires that hosts be able to receive periodic multicast RAs [RFC4861]. Hosts that process unicast packets while they are asleep must also process multicast RAs while they are asleep. An excessive number of RAs can significantly reduce the battery life of mobile hosts. [RFC7772] (Best Current Practice) specifies a solution to reduce RAs:
IPv6 接続を維持するには、ホストが定期的なマルチキャスト RA [RFC4861] を受信できる必要があります。スリープ中にユニキャスト パケットを処理するホストは、スリープ中にマルチキャスト RA も処理する必要があります。RA の数が多すぎると、モバイル ホストのバッテリ寿命が大幅に短くなる可能性があります。[RFC7772] (現在のベストプラクティス) では、RA を削減するためのソリューションが指定されています。
* The router should respond to RS with unicast RA (rather than the normal multicast RA) if the host's source IP address is specified and the host's MAC address is valid. This way, other hosts will not receive this RA.
* ホストの送信元 IP アドレスが指定され、ホストの MAC アドレスが有効な場合、ルータは (通常のマルチキャスト RA ではなく) ユニキャスト RA で RS に応答する必要があります。こうすることで、他のホストはこの RA を受信しなくなります。
* The router should reduce the multicast RA frequency.
* ルーターはマルチキャスト RA の頻度を減らす必要があります。
[RFC7772] addresses Issue 2 (Section 2.1).
[RFC7772] は問題 2 (セクション 2.1) に対処しています。
GRAND [RFC9131] (Standards Track) changes ND in the following ways:
GRAND [RFC9131] (標準化トラック) は、次の方法で ND を変更します。
* A node sends unsolicited NAs upon assigning a new IPv6 address to its interface.
* ノードは、そのインターフェイスに新しい IPv6 アドレスを割り当てると、要求されていない NA を送信します。
* A router creates a new NCE for the node and sets its state to STALE.
* ルーターはノードの新しい NCE を作成し、その状態を STALE に設定します。
When a packet for the host later arrives, the router can use the existing STALE NCE to forward it immediately ([RFC4861], Section 7.2.2). It then verifies reachability by sending a unicast NS rather than a multicast one for address resolution. In this way, GRAND eliminates the router forwarding delay, but it does not solve other Router-NCE-on-Demand issues. For example, NCE exhaustion can still happen.
後でホスト宛てのパケットが到着すると、ルータは既存の STALE NCE を使用してそれを即座に転送できます ([RFC4861]、セクション 7.2.2)。次に、アドレス解決のためにマルチキャスト NS ではなくユニキャスト NS を送信することで到達可能性を検証します。このように、GRAND はルータの転送遅延を解消しますが、他の Router-NCE-on-Demand の問題は解決しません。たとえば、NCE 枯渇は依然として発生する可能性があります。
Source Address Validation Improvement (SAVI) [RFC7039] (Informational) binds an address to a port on an L2 switch and rejects claims from other ports for that address. Therefore, a node cannot spoof the IP address of another node.
Source Address Validation Improvement (SAVI) [RFC7039] (情報) は、アドレスを L2 スイッチ上のポートにバインドし、そのアドレスに対する他のポートからの要求を拒否します。したがって、ノードは別のノードの IP アドレスを偽装することはできません。
Router Advertisement Guard (RA-Guard) [RFC6105] [RFC7113] (Informational) only allows RAs from a port that a router is connected to. Therefore, nodes on other ports cannot pretend to be a router.
Router Advertising Guard (RA-Guard) [RFC6105] [RFC7113] (情報) は、ルーターが接続されているポートからの RA のみを許可します。したがって、他のポート上のノードはルーターのふりをすることができません。
SAVI and RA-Guard address the on-link security issues.
SAVI と RA-Guard は、リンク上のセキュリティ問題に対処します。
[RFC6583] (Informational) deals with the NCE exhaustion attack issue (Section 2.3). It recommends that:
[RFC6583] (情報) は NCE 枯渇攻撃の問題を扱っています (セクション 2.3)。次のことを推奨します。
* Operators should:
* オペレーターは次のことを行う必要があります。
- Filter unused address space so that messages to such addresses can be dropped rather than triggering NCE creation.
- 未使用のアドレス空間をフィルタリングして、そのようなアドレスへのメッセージが NCE 作成をトリガーせずにドロップできるようにします。
- Implement rate-limiting mechanisms for ND message processing to prevent CPU and memory resources from being overwhelmed.
- ND メッセージ処理にレート制限メカニズムを実装して、CPU とメモリのリソースが過剰になるのを防ぎます。
* Vendors should:
* ベンダーは次のことを行う必要があります。
- Prioritize NDP processing for existing NCEs over creating new NCEs.
- 新しい NCE の作成よりも、既存の NCE の NDP 処理を優先します。
[RFC6583] acknowledges that "some of these options are 'kludges', and can be operationally difficult to manage". [RFC6583] partially addresses the Router NCE exhaustion issue. In practice, router vendors cap the number of NCEs per interface to prevent cache exhaustion. If the link has more addresses than that cap, the router cannot keep an entry for every address, and packets destined for addresses without an NCE are simply dropped [RFC9663].
[RFC6583] は、「これらのオプションの一部は『クラッジ』であり、運用上管理が難しい場合がある」ことを認めています。[RFC6583] はルーター NCE 枯渇の問題に部分的に対処しています。実際には、ルータ ベンダーはキャッシュの枯渇を防ぐために、インターフェイスごとの NCE の数に制限を設けています。リンクにその上限を超えるアドレスがある場合、ルータはすべてのアドレスのエントリを保持できず、NCE のないアドレス宛てのパケットは単純にドロップされます [RFC9663]。
In IPv4, network administrators can retrieve a host's IP address from the DHCP server and use it for subscriber management. In IPv6 and SLAAC, this is not possible (Section 2.3).
IPv4 では、ネットワーク管理者は DHCP サーバーからホストの IP アドレスを取得し、それを加入者管理に使用できます。IPv6 および SLAAC では、これは不可能です (セクション 2.3)。
[RFC9686] (Standards Track) defines a method for informing a DHCPv6 server that a host has one or more self-generated or statically configured addresses. This enables network administrators to retrieve the IPv6 addresses for each host from the DHCPv6 server. [RFC9686] provides a solution for Issue 15 (Section 2.3).
[RFC9686] (Standards Track) は、ホストが 1 つ以上の自己生成または静的に構成されたアドレスを持っていることを DHCPv6 サーバーに通知する方法を定義しています。これにより、ネットワーク管理者は DHCPv6 サーバーから各ホストの IPv6 アドレスを取得できるようになります。[RFC9686] は問題 15 (セクション 2.3) の解決策を提供します。
Enhanced DAD [RFC7527] (Standards Track) addresses a DAD failure issue in a specific situation: a looped-back interface. DAD will fail in a looped-back interface because the sending host will receive the DAD message back and will interpret it as another host is trying to use the same address. The solution is to include a Nonce option [RFC3971] in each DAD message so that the sending host can detect that the looped-back DAD message is sent by itself.
拡張 DAD [RFC7527] (Standards Track) は、ループバック インターフェイスという特定の状況における DAD 障害の問題に対処します。送信側ホストが DAD メッセージを受信し、別のホストが同じアドレスを使用しようとしていると解釈してしまうため、DAD はループバック インターフェイスで失敗します。解決策は、各 DAD メッセージに Nonce オプション [RFC3971] を含めて、ループバックされた DAD メッセージがそれ自体で送信されたことを送信側ホストが検出できるようにすることです。
Enhanced DAD does not solve any ND issue. It extends ND to work in a new scenario: a looped-back interface. It is reviewed here only for completeness.
拡張 DAD では ND の問題は解決されません。これは、ループバック インターフェイスという新しいシナリオで動作するように ND を拡張します。ここでは完全を期すためにのみレビューします。
ND mediation is specified in [RFC6575] (Standards Track). When two Attachment Circuits (ACs) are interconnected by a Virtual Private Wired Service (VPWS), and the two ACs are of different media (e.g., one is Ethernet while the other is Frame Relay), the two PEs must interwork to provide mediation service so that a Customer Edge (CE) can resolve the MAC address of the remote end. [RFC6575] specifies such a solution.
ND 調停は [RFC6575] (Standards Track) で規定されています。2 つの接続回線 (AC) が仮想プライベート ワイヤード サービス (VPWS) によって相互接続されており、2 つの AC が異なるメディアである場合 (たとえば、1 つはイーサネット、もう 1 つはフレーム リレー)、カスタマー エッジ (CE) がリモート エンドの MAC アドレスを解決できるように、2 つの PE が相互作用して仲介サービスを提供する必要があります。[RFC6575] はそのような解決策を指定しています。
ND mediation does not address any ND issue. It extends ND to work in a new scenario: two ACs of different media interconnected by a VPWS. It is reviewed here only for completeness.
ND 調停では、ND 問題は扱われません。これは、VPWS によって相互接続された異なるメディアの 2 つの AC という新しいシナリオで動作するように ND を拡張します。ここでは完全を期すためにのみレビューします。
The latest versions of ND and SLAAC are specified in [RFC4861] and [RFC4862]. Several ND mitigation solutions were published before [RFC4861]. They are reviewed in this section only for completeness.
ND および SLAAC の最新バージョンは [RFC4861] および [RFC4862] で規定されています。[RFC4861] より前に、いくつかの ND 緩和ソリューションが公開されました。このセクションでは、完全を期すためにのみレビューされます。
The purpose of SEND [RFC3971] (Standards Track) is to ensure that hosts and routers are trustworthy. SEND defined three new ND options: Cryptographically Generated Addresses (CGA) [RFC3972] (Standards Track), RSA public-key cryptosystem, and Timestamp/Nonce. In addition, SEND also defined an authorization delegation discovery process, an address ownership proof mechanism, and requirements for the use of these components in the ND protocol.
SEND [RFC3971] (Standards Track) の目的は、ホストとルーターが信頼できることを保証することです。SEND は、Cryptographically Generated Addresses (CGA) [RFC3972] (Standards Track)、RSA 公開キー暗号システム、および Timestamp/Nonce の 3 つの新しい ND オプションを定義しました。さらに、SEND では、認可委任の検出プロセス、アドレス所有権証明メカニズム、および ND プロトコルでのこれらのコンポーネントの使用要件も定義されています。
The purpose of CGA is to associate a cryptographic public key with an IPv6 address in the SEND protocol. The key point is to generate the Interface Identifier (IID) of an IPv6 address by computing a cryptographic hash of the public key. The resulting IPv6 address is called a CGA. The corresponding private key can then be used to sign messages sent from the address.
CGA の目的は、SEND プロトコルで暗号化公開キーを IPv6 アドレスに関連付けることです。重要な点は、公開キーの暗号化ハッシュを計算して、IPv6 アドレスのインターフェイス識別子 (IID) を生成することです。結果として得られる IPv6 アドレスは CGA と呼ばれます。対応する秘密キーを使用して、そのアドレスから送信されるメッセージに署名できます。
CGA assumes that a legitimate host does not care about the bit combination of the IID that would be created by some hash procedure. The attacker needs an exact IID to impersonate the legitimate hosts, but then the attacker is challenged to do a reverse hash calculation, which is a strong mathematical challenge.
CGA は、正当なホストは、ハッシュ手順によって作成される IID のビットの組み合わせを気にしないと想定しています。攻撃者は正規のホストになりすますために正確な IID を必要としますが、その場合、攻撃者は逆ハッシュ計算を実行するように要求されます。これは強力な数学的課題です。
CGA is part of SEND. There is no reported deployment.
CGA は SEND の一部です。導入の報告はありません。
ND Proxy [RFC4389] (Experimental) aims to enable multiple links joined by an ND Proxy device to work as a single link.
ND プロキシ [RFC4389] (実験的) は、ND プロキシ デバイスによって結合された複数のリンクが単一のリンクとして機能できるようにすることを目的としています。
* When an ND Proxy receives an ND request from a host on a link, it will proxy the message out the "best" (defined in the next paragraph) outgoing interface. If there is no best interface, the ND Proxy will proxy the message to all other links. Here, proxy means acting as if the ND message originates from the ND Proxy itself. That is, the ND Proxy will change the ND message's source IP and source MAC address to the ND Proxy's outgoing interface's IP and MAC address, and create an NCE entry at the outgoing interface accordingly.
* ND プロキシは、リンク上のホストから ND 要求を受信すると、「最適な」 (次の段落で定義される) 発信インターフェイスからメッセージをプロキシ出力します。最適なインターフェイスがない場合、ND プロキシはメッセージを他のすべてのリンクにプロキシします。ここで、プロキシとは、ND メッセージが ND プロキシ自体から発信されているかのように動作することを意味します。つまり、ND プロキシは、ND メッセージの送信元 IP および送信元 MAC アドレスを ND プロキシの送信インターフェイスの IP および MAC アドレスに変更し、それに応じて送信インターフェイスに NCE エントリを作成します。
* When ND Proxy receives an ND reply, it will act as if the ND message is destined for itself, and update the NCE entry state at the receiving interface. Based on such state information, the ND Proxy can determine the "best" outgoing interface for future ND requests. The ND Proxy then proxies the ND message back to the requesting host.
* ND プロキシは、ND 応答を受信すると、ND メッセージが自分自身に宛てられたものであるかのように動作し、受信インターフェイスで NCE エントリ状態を更新します。このような状態情報に基づいて、ND プロキシは、将来の ND 要求に「最適な」発信インターフェイスを決定できます。次に、ND プロキシは、ND メッセージをプロキシとして要求側ホストに返します。
ND Proxy is widely used in SARP (Section 3.5), ND optimization for TRILL (Section 3.6), and Proxy ARP/ND in EVPN (Section 3.7).
ND プロキシは、SARP (セクション 3.5)、TRILL の ND 最適化 (セクション 3.6)、および EVPN のプロキシ ARP/ND (セクション 3.7) で広く使用されています。
Optimistic DAD [RFC4429] (Standards Track) seeks to minimize address configuration delays in the successful case and to reduce disruption as far as possible in the failure case. That is, Optimistic DAD lets hosts immediately use the newly formed address to communicate before DAD completes, assuming that DAD will succeed anyway. If the address turns out to be duplicate, Optimistic DAD provides a set of mechanisms to minimize the impact. Optimistic DAD modified the original ND [RFC2461] and original SLAAC [RFC2462] (both of which are obsolete), but the solution was not incorporated into the latest specifications of ND [RFC4861] and SLAAC [RFC4862]. However, implementations of Optimistic DAD exist.
Optimistic DAD [RFC4429] (Standards Track) は、成功した場合のアドレス構成の遅延を最小限に抑え、失敗した場合の中断を可能な限り減らすことを目指しています。つまり、Optimistic DAD では、DAD が成功することを前提として、DAD が完了する前にホストが新しく形成されたアドレスをすぐに使用して通信できるようになります。アドレスが重複していることが判明した場合、Optimistic DAD は影響を最小限に抑える一連のメカニズムを提供します。Optimistic DAD はオリジナルの ND [RFC2461] とオリジナルの SLAAC [RFC2462] (どちらも廃止されました) を修正しましたが、その解決策は ND [RFC4861] と SLAAC [RFC4862] の最新の仕様には組み込まれていませんでした。ただし、Optimistic DAD の実装は存在します。
Optimistic DAD does not solve any ND issue (Section 2). It is reviewed here only for completeness.
楽観的な DAD は ND 問題を解決しません (セクション 2)。ここでは完全を期すためにのみレビューします。
By knowing the potential ND issues and associated mitigation solutions, network administrators of existing IPv6 deployments can assess whether these issues may occur in their networks and, if so, whether to deploy the mitigation solutions proactively. Deploying these solutions may take time and additional resources. Therefore, it is advisable to plan.
潜在的な ND の問題と関連する緩和ソリューションを知ることで、既存の IPv6 導入のネットワーク管理者は、これらの問題がネットワークで発生する可能性があるかどうか、発生する場合は緩和ソリューションを積極的に導入するかどうかを評価できます。これらのソリューションの導入には時間と追加のリソースがかかる場合があります。したがって、計画を立てることをお勧めします。
Network administrators planning to start their IPv6 deployments can use the issue-solution information to help plan their deployments. Moreover, they can take proactive action to prevent potential ND issues.
IPv6 導入の開始を計画しているネットワーク管理者は、問題解決情報を利用して導入計画を立てることができます。さらに、潜在的な ND 問題を防ぐために積極的な行動をとることができます。
While various ND solutions may initially appear unrelated, categorizing them into four distinct groups highlights an important observation: host isolation is an effective strategy for mitigating ND-related issues.
さまざまな ND ソリューションは最初は無関係に見えるかもしれませんが、それらを 4 つの異なるグループに分類すると、ホストの分離が ND 関連の問題を軽減する効果的な戦略であるという重要な観察結果が浮き彫りになります。
* Group 1: L3 and L2 Isolation
* グループ 1: L3 および L2 分離
This group includes MBBv6 and FBBv6, which isolate hosts at both L3 and L2 by placing each host within its subnet and link. This prevents ND issues caused by multicast and Trusting-all-nodes, as each host operates within its isolated domain. Furthermore, since routers can route packets to a host based on its unique prefix, the need for Router-NCE-on-Demand is also eliminated. Therefore, L3 and L2 Isolation prevent all ND issues.
このグループには MBBv6 と FBBv6 が含まれており、各ホストをそのサブネットとリンク内に配置することで L3 と L2 の両方でホストを分離します。これにより、各ホストが分離されたドメイン内で動作するため、マルチキャストや全ノードの信頼によって引き起こされる ND の問題が防止されます。さらに、ルータは固有のプレフィックスに基づいてホストにパケットをルーティングできるため、Router-NCE-on-Demand の必要性もなくなります。したがって、L3 および L2 分離により、ND の問題がすべて防止されます。
* Group 2: L3 Isolation
* グループ 2: L3 分離
This group includes UPPH solutions like [RFC8273] and [RFC9663], which isolate hosts into separate subnets while potentially leaving them on the same shared medium. This approach mitigates ND issues caused by router multicast to hosts and eliminates the need for Router-NCE-on-Demand, as detailed in Section 3.3.
このグループには、[RFC8273] や [RFC9663] のような UPPH ソリューションが含まれており、ホストを別々のサブネットに分離し、ホストを同じ共有メディア上に残す可能性があります。このアプローチにより、ホストへのルータのマルチキャストによって引き起こされる ND の問題が軽減され、セクション 3.3 で詳しく説明されている Router-NCE-on-Demand の必要性がなくなります。
* Group 3: Partial L2 Isolation
* グループ 3: 部分的な L2 分離
This group encompasses solutions such as WiND, SARP, ND optimization for TRILL, and Proxy ND in EVPN. These solutions use a proxy device to represent the hosts behind it, effectively isolating those hosts into distinct multicast domains. While hosts are still located within the same subnet, their separation into different multicast domains reduces the scope of ND issues related to multicast-based address resolution.
このグループには、WiND、SARP、TRILL の ND 最適化、EVPN のプロキシ ND などのソリューションが含まれます。これらのソリューションでは、プロキシ デバイスを使用して背後のホストを表し、それらのホストを個別のマルチキャスト ドメインに効果的に分離します。ホストは依然として同じサブネット内に配置されていますが、ホストが異なるマルチキャスト ドメインに分離されているため、マルチキャスト ベースのアドレス解決に関連する ND 問題の範囲が縮小されます。
* Group 4: Non-Isolating Solutions
* グループ 4: 非絶縁ソリューション
The final group includes remaining solutions that do not implement host isolation. These solutions do not prevent ND issues but instead focus on addressing specific ND problems.
最後のグループには、ホスト分離を実装していない残りのソリューションが含まれます。これらのソリューションは ND の問題を防ぐものではなく、特定の ND 問題に対処することに重点を置いています。
The analysis demonstrates that the stronger the isolation of hosts, the more ND issues can be mitigated. This correlation is intuitive, as isolating hosts reduces the multicast scope, minimizes the number of nodes that must be trusted, and may eliminate the need for Router-NCE-on-Demand, the three primary causes of ND issues.
この分析は、ホストの分離が強化されるほど、ND の問題をより多く軽減できることを示しています。ホストを分離するとマルチキャストの範囲が減り、信頼する必要があるノードの数が最小限に抑えられ、ND 問題の 3 つの主な原因である Router-NCE-on-Demand の必要性がなくなる可能性があるため、この相関関係は直感的です。
This understanding can be used to prevent ND issues.
この理解は、ND の問題を防ぐために使用できます。
Benefits:
利点：
* All ND issues (Section 2.4) can be effectively mitigated.
* すべての ND 問題 (セクション 2.4) は効果的に軽減できます。
Constraints:
制約:
1. L2 Isolation:
1. L2分離:
Actions must be taken to isolate hosts in L2. The required effort varies by the chosen method and deployment context. For example, the P2P method [RFC7066] is heavyweight, while the Private VLAN method [RFC5517] is more manageable.
L2 でホストを隔離するための措置を講じる必要があります。必要な作業は、選択した方法と展開コンテキストによって異なります。たとえば、P2P 方式 [RFC7066] は負荷が高いのに対し、プライベート VLAN 方式 [RFC5517] はより管理しやすいです。
2. Unique prefix allocation:
2. 一意のプレフィックス割り当て:
A large number of prefixes will be required, with one prefix assigned per host. This is generally not a limitation for IPv6. For instance, members of a Regional Internet Registry (RIR) can obtain a /29 prefix allocation [RIPE738], which provides 32 billion /64 prefixes -- sufficient for any foreseeable deployment scenarios. Practical implementations, such as MBBv6 assigning /64 prefixes to billions of mobile UEs [RFC6459], and FBBv6 assigning /56 prefixes to hundreds of millions of routed RGs [TR177], demonstrate the feasibility of this approach.
ホストごとに 1 つのプレフィックスが割り当てられるため、多数のプレフィックスが必要になります。通常、これは IPv6 の制限ではありません。たとえば、地域インターネット レジストリ (RIR) のメンバーは、/29 プレフィックス割り当て [RIPE738] を取得できます。これにより、予測可能な展開シナリオには十分な、320 億の /64 プレフィックスが提供されます。MBBv6 が数十億のモバイル UE に /64 プレフィックスを割り当てる [RFC6459] や、FBBv6 が数億のルーティングされた RG に /56 プレフィックスを割り当てる [TR177] などの実際的な実装は、このアプローチの実現可能性を示しています。
3. Privacy issue from unique prefix identifiability:
3. 一意のプレフィックスの識別可能性によるプライバシーの問題:
Assigning a unique prefix to each host may theoretically reduce privacy, as hosts can be directly identified by their assigned prefix. However, alternative host identification methods, such as cookies, are commonly used. Therefore, unique prefix identifiability may not make much difference. The actual impact on privacy is therefore likely to be limited.
各ホストに一意のプレフィックスを割り当てると、ホストは割り当てられたプレフィックスによって直接識別される可能性があるため、理論的にはプライバシーが低下する可能性があります。ただし、Cookie などの代替のホスト識別方法が一般的に使用されます。したがって、一意のプレフィックスの識別可能性は大きな違いを生まない可能性があります。したがって、プライバシーへの実際の影響は限定的であると考えられます。
4. Router support for L3 Isolation:
4. L3 分離に対するルーターのサポート:
The router must support an L3 Isolation solution, e.g., [RFC8273] or [RFC9663].
ルータは、[RFC8273] または [RFC9663] などの L3 分離ソリューションをサポートする必要があります。
5. A large number of router interfaces may be needed:
5. 多数のルーター インターフェイスが必要になる場合があります。
If the P2P method is used, the router must instantiate a separate logical interface for every attached host. In this case, a large number of interfaces will be needed at the router.
P2P 方式を使用する場合、ルーターは接続されているホストごとに個別の論理インターフェイスをインスタンス化する必要があります。この場合、ルーターには多数のインターフェイスが必要になります。
6. Router as a bottleneck:
6. ボトルネックとしてのルーター:
Since all communication between hosts is routed through the router, the router may become a performance bottleneck in high-traffic scenarios.
ホスト間のすべての通信はルーターを介してルーティングされるため、トラフィックが多いシナリオではルーターがパフォーマンスのボトルネックになる可能性があります。
7. Incompatibility with host-based multicast services:
7. ホストベースのマルチキャスト サービスとの非互換性:
Services that rely on multicast communication among hosts, such as the Multicast Domain Name System [RFC6762], will be disrupted.
マルチキャスト ドメイン ネーム システム [RFC6762] など、ホスト間のマルチキャスト通信に依存するサービスは中断されます。
Benefits:
利点：
* All ND issues (Section 2.4) are mitigated, with the exception of:
* 以下を除くすべての ND 問題 (セクション 2.4) が軽減されます。
- LLA DAD multicast degrades performance,
- LLA DAD マルチキャストはパフォーマンスを低下させます。
- LLA DAD not reliable in wireless networks, and
- LLA DAD はワイヤレス ネットワークでは信頼できません。
- on-link security.
- オンリンクセキュリティ。
These remaining issues depend on the characteristics of the shared medium:
これらの残りの問題は、共有メディアの特性によって異なります。
- If the shared medium is Ethernet, the issues related to LLA DAD multicast are negligible.
- 共有メディアがイーサネットの場合、LLA DAD マルチキャストに関連する問題は無視できます。
- If nodes can be trusted, such as in private networks, on-link security concerns are not significant.
- プライベート ネットワークなどでノードが信頼できる場合、リンク上のセキュリティの問題は重大ではありません。
* There is no need for L2 Isolation. Consequently, this method can be applied in a wide range of scenarios, making it possibly the most practical host isolation method.
* L2分離は必要ありません。したがって、この方法は幅広いシナリオに適用でき、おそらく最も実用的なホスト分離方法になります。
Constraints (as discussed in Section 4.2.1):
制約 (セクション 4.2.1 で説明):
1. Unique prefix allocation
1. 固有のプレフィックス割り当て
2. Router support for L3 Isolation
2. ルーターによる L3 分離のサポート
3. Router as a bottleneck
3. ボトルネックとしてのルーター
4. Privacy issue from unique prefix identifiability
4. 一意のプレフィックスの識別可能性によるプライバシーの問題
Benefit:
利点：
* Reduced multicast traffic: This method reduces multicast traffic, particularly for address resolution, by dividing the subnet into multiple multicast domains.
* マルチキャスト トラフィックの削減: この方法では、サブネットを複数のマルチキャスト ドメインに分割することにより、特にアドレス解決のためのマルチキャスト トラフィックが削減されます。
Constraint:
制約:
* Router support for Partial L2 Isolation: The router must implement a Partial L2 Isolation solution such as WiND, SARP, ND optimization for TRILL, and Proxy ND in EVPN to support this method.
* 部分 L2 分離のルーター サポート: この方法をサポートするには、ルーターは WiND、SARP、TRILL の ND 最適化、EVPN のプロキシ ND などの部分 L2 分離ソリューションを実装する必要があります。
Based on the applicability analysis provided in the preceding sections, network administrators can determine whether to implement an isolation method and, if so, which method is most appropriate for their specific deployment.
前のセクションで説明した適用性分析に基づいて、ネットワーク管理者は分離方法を実装するかどうか、実装する場合はどの方法が特定の展開に最も適しているかを判断できます。
A simple guideline is to consider the isolation methods in the order listed in the preceding sections, progressing from the strongest isolation to the weakest:
簡単なガイドラインは、前のセクションにリストされている順序で、最も強力な分離から最も弱い分離まで順に分離方法を検討することです。
* Stronger isolation methods can prevent more ND issues, but may also impose higher entry requirements.
* 分離方法を強化すると、より多くの ND 問題を防ぐことができますが、より高いエントリ要件が課される可能性もあります。
* Weaker isolation methods have fewer entry requirements but may leave some ND issues unmitigated.
* 弱い分離方法ではエントリ要件が少なくなりますが、一部の ND 問題が軽減されないままになる可能性があります。
The choice between L3+L2 Isolation and L3 Isolation often depends on the cost of implementing L2 Isolation:
L3+L2 分離と L3 分離のどちらを選択するかは、多くの場合、L2 分離の実装コストによって決まります。
* If the cost is acceptable, L3+L2 Isolation is preferable because it eliminates every ND issue listed in Section 2.4.
* コストが許容できる場合は、セクション 2.4 にリストされているすべての ND 問題が排除されるため、L3+L2 分離が推奨されます。
* Otherwise, L3 Isolation addresses most of those issues while keeping the implementation effort reasonable.
* それ以外の場合、L3 分離は、実装の労力を合理的に保ちながら、これらの問題のほとんどに対処します。
Selecting an isolation method that is either too strong or too weak does not result in serious consequences:
強すぎる分離方法または弱すぎる分離方法を選択しても、重大な結果が生じることはありません。
* Choosing an overly strong isolation method may require the network administrator to meet higher entry requirements initially, such as measures for L2 Isolation, additional prefixes, or additional router capabilities.
* 過度に強力な分離方法を選択すると、ネットワーク管理者は最初に、L2 分離、追加のプレフィックス、または追加のルーター機能などのより高いエントリ要件を満たすことが必要になる場合があります。
* Choosing a weaker isolation method may necessitate deploying supplemental ND mitigation techniques to address any unresolved ND issues.
* より弱い分離方法を選択すると、未解決の ND 問題に対処するために、補足的な ND 軽減技術の導入が必要になる場合があります。
In either case, the resulting solution can be functional and effective.
どちらの場合でも、結果として得られるソリューションは機能的で効果的です。
This document is a review of known ND issues and solutions, including security. It does not introduce any new solutions. Therefore, it does not introduce new security issues.
この文書は、セキュリティを含む既知の ND の問題と解決策を概説したものです。新しい解決策は導入されません。したがって、新たなセキュリティ問題が発生することはありません。
This document has no IANA actions.
この文書には IANA のアクションはありません。
[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>.
[AddrAcc] Chown, T., Cummings, C., and D. W. Carder, "IPv6 Address
Accountability Considerations", Work in Progress,
Internet-Draft, draft-ccc-v6ops-address-accountability-00,
21 October 2024, <https://datatracker.ietf.org/doc/html/
draft-ccc-v6ops-address-accountability-00>.
[MADINAS] Henry, J. and Y. Lee, "Randomized and Changing Media
Access Control (MAC) Addresses: Context, Network Impacts,
and Use Cases", RFC 9797, DOI 10.17487/RFC9797, June 2025,
<https://www.rfc-editor.org/info/rfc9797>.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
<https://www.rfc-editor.org/info/rfc2026>.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
DOI 10.17487/RFC2461, December 1998,
<https://www.rfc-editor.org/info/rfc2461>.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, DOI 10.17487/RFC2462,
December 1998, <https://www.rfc-editor.org/info/rfc2462>.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587,
August 2003, <https://www.rfc-editor.org/info/rfc3587>.
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
Neighbor Discovery (ND) Trust Models and Threats",
RFC 3756, DOI 10.17487/RFC3756, May 2004,
<https://www.rfc-editor.org/info/rfc3756>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005,
<https://www.rfc-editor.org/info/rfc3971>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>.
[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>.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April
2006, <https://www.rfc-editor.org/info/rfc4389>.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
<https://www.rfc-editor.org/info/rfc4429>.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
DOI 10.17487/RFC4903, June 2007,
<https://www.rfc-editor.org/info/rfc4903>.
[RFC5517] HomChaudhuri, S. and M. Foschiano, "Cisco Systems' Private
VLANs: Scalable Security in a Multi-Client Environment",
RFC 5517, DOI 10.17487/RFC5517, February 2010,
<https://www.rfc-editor.org/info/rfc5517>.
[RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec,
"Address Mapping of IPv6 Multicast Packets on Ethernet",
RFC 6085, DOI 10.17487/RFC6085, January 2011,
<https://www.rfc-editor.org/info/rfc6085>.
[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>.
[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen,
T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
Partnership Project (3GPP) Evolved Packet System (EPS)",
RFC 6459, DOI 10.17487/RFC6459, January 2012,
<https://www.rfc-editor.org/info/rfc6459>.
[RFC6575] Shah, H., Ed., Rosen, E., Ed., Heron, G., Ed., and V.
Kompella, Ed., "Address Resolution Protocol (ARP)
Mediation for IP Interworking of Layer 2 VPNs", RFC 6575,
DOI 10.17487/RFC6575, June 2012,
<https://www.rfc-editor.org/info/rfc6575>.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583,
DOI 10.17487/RFC6583, March 2012,
<https://www.rfc-editor.org/info/rfc6583>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>.
[RFC6957] Costa, F., Combes, J., Ed., Pougnard, X., and H. Li,
"Duplicate Address Detection Proxy", RFC 6957,
DOI 10.17487/RFC6957, June 2013,
<https://www.rfc-editor.org/info/rfc6957>.
[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>.
[RFC7066] Korhonen, J., Ed., Arkko, J., Ed., Savolainen, T., and S.
Krishnan, "IPv6 for Third Generation Partnership Project
(3GPP) Cellular Hosts", RFC 7066, DOI 10.17487/RFC7066,
November 2013, <https://www.rfc-editor.org/info/rfc7066>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <https://www.rfc-editor.org/info/rfc7102>.
[RFC7113] Gont, F., "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)", RFC 7113,
DOI 10.17487/RFC7113, February 2014,
<https://www.rfc-editor.org/info/rfc7113>.
[RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6
/64 Prefix from a Third Generation Partnership Project
(3GPP) Mobile Interface to a LAN Link", RFC 7278,
DOI 10.17487/RFC7278, June 2014,
<https://www.rfc-editor.org/info/rfc7278>.
[RFC7342] Dunbar, L., Kumari, W., and I. Gashinsky, "Practices for
Scaling ARP and Neighbor Discovery (ND) in Large Data
Centers", RFC 7342, DOI 10.17487/RFC7342, August 2014,
<https://www.rfc-editor.org/info/rfc7342>.
[RFC7527] Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E.,
and W. George, "Enhanced Duplicate Address Detection",
RFC 7527, DOI 10.17487/RFC7527, April 2015,
<https://www.rfc-editor.org/info/rfc7527>.
[RFC7586] Nachum, Y., Dunbar, L., Yerushalmi, I., and T. Mizrahi,
"The Scalable Address Resolution Protocol (SARP) for Large
Data Centers", RFC 7586, DOI 10.17487/RFC7586, June 2015,
<https://www.rfc-editor.org/info/rfc7586>.
[RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy
Consumption of Router Advertisements", BCP 202, RFC 7772,
DOI 10.17487/RFC7772, February 2016,
<https://www.rfc-editor.org/info/rfc7772>.
[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
<https://www.rfc-editor.org/info/rfc8273>.
[RFC8302] Li, Y., Eastlake 3rd, D., Dunbar, L., Perlman, R., and M.
Umair, "Transparent Interconnection of Lots of Links
(TRILL): ARP and Neighbor Discovery (ND) Optimization",
RFC 8302, DOI 10.17487/RFC8302, January 2018,
<https://www.rfc-editor.org/info/rfc8302>.
[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>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>.
[RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik,
"Address-Protected Neighbor Discovery for Low-Power and
Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November
2020, <https://www.rfc-editor.org/info/rfc8928>.
[RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli,
"IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929,
November 2020, <https://www.rfc-editor.org/info/rfc8929>.
[RFC9099] Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey,
"Operational Security Considerations for IPv6 Networks",
RFC 9099, DOI 10.17487/RFC9099, August 2021,
<https://www.rfc-editor.org/info/rfc9099>.
[RFC9119] Perkins, C., McBride, M., Stanley, D., Kumari, W., and JC.
Zúñiga, "Multicast Considerations over IEEE 802 Wireless
Media", RFC 9119, DOI 10.17487/RFC9119, October 2021,
<https://www.rfc-editor.org/info/rfc9119>.
[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>.
[RFC9161] Rabadan, J., Ed., Sathappan, S., Nagaraj, K., Hankins, G.,
and T. King, "Operational Aspects of Proxy ARP/ND in
Ethernet Virtual Private Networks", RFC 9161,
DOI 10.17487/RFC9161, January 2022,
<https://www.rfc-editor.org/info/rfc9161>.
[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>.
[RFC9686] Kumari, W., Krishnan, S., Asati, R., Colitti, L., Linkova,
J., and S. Jiang, "Registering Self-Generated IPv6
Addresses Using DHCPv6", RFC 9686, DOI 10.17487/RFC9686,
December 2024, <https://www.rfc-editor.org/info/rfc9686>.
[RIPE738] RIPE, "IPv6 Address Allocation and Assignment Policy",
RIPE-738, March 2020,
<https://www.ripe.net/publications/docs/ripe-738>.
[SND] Thubert, P. and M. Richardson, "Architecture and Framework
for IPv6 over Non-Broadcast Access", Work in Progress,
Internet-Draft, draft-ietf-6man-ipv6-over-wireless-09, 9
November 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-6man-ipv6-over-wireless-09>.
[TR177] Broadband Forum, "IPv6 in the context of TR-101", TR-177,
November 2017,
<https://www.broadband-forum.org/pdfs/tr-177-1-0-1.pdf>.
The authors would like to thank Éric Vyncke, Gunter Van de Velde, Lorenzo Colitti, Erik Kline, Warren Kumari, Mohamed Boucadair, Gorry Fairhurst, Pascal Thubert, Jen Linkova, Brian Carpenter, Mike Ackermann, Nalini Elkins, Ed Horley, Ole Troan, David Thaler, Chongfeng Xie, Chris Cummings, Dale Carder, Tim Chown, Priyanka Sinha, Aijun Wang, Ines Robles, Magnus Westerlund, Barry Leiba, Deb Cooley, and Paul Wouters for their reviews and comments. The authors would also like to thank Tim Winters for being the document shepherd.
著者らは、Éric Vyncke、Gunter Van de Velde、Lorenzo Colitti、Erik Kline、Warren Kumari、Mohamed Boucadair、Gorry Fairhurst、Pascal Thubert、Jen Linkova、Brian Carpenter、Mike Ackermann、Nalini Elkins、Ed Horley、Ole Troan、David Thaler、Chongfeng Xie、Chris Cummings、Dale Carder、に感謝します。Tim Cown、Priyanka Sinha、Aijun Wang、Ines Robles、Magnus Westerlund、Barry Leiba、Deb Cooley、Paul Wouters からレビューとコメントをいただきました。著者らはまた、文書の管理者である Tim Winters に感謝したいと思います。
XiPeng Xiao
Huawei Technologies
Email: xipengxiao@huawei.com
Eduard Vasilenko
Huawei Technologies
Email: vasilenko.eduard@huawei.com
Eduard Metz
KPN N.V.
Email: eduard.metz@kpn.com
Gyan Mishra
Verizon Inc.
Email: gyan.s.mishra@verizon.com
Nick Buraglio
Energy Sciences Network
Email: buraglio@es.net