Internet Engineering Task Force (IETF) P. Thubert, Ed.
Request for Comments: 9926 February 2026
Updates: 4861, 6550, 8505, 8928, 9010
Category: Standards Track
ISSN: 2070-1721
This document updates IPv6 Neighbor Discovery (RFC 4861) and IPv6 Subnet Neighbor Discovery (RFC 8505, RFC 8928) to enable a node that owns or is directly connected to a prefix to register that prefix to neighbor routers. The registration indicates that the registered prefix can be reached via the advertising node without a loop. The unicast prefix registration allows the node to request one or more neighbor routers to redistribute the prefix in another routing domain regardless of the routing protocol used in that domain. This document updates the Routing Protocol for Low-Power and Lossy Networks (RPL), as specified in RFCs 6550 and 9010, to enable a 6LoWPAN Router (6LR) to inject the registered prefix in RPL.
この文書は、IPv6 近隣探索 (RFC 4861) および IPv6 サブネット近隣探索 (RFC 8505、RFC 8928) を更新し、プレフィックスを所有するノードまたはプレフィックスに直接接続されているノードがそのプレフィックスを近隣ルータに登録できるようにします。登録は、登録されたプレフィックスが広告ノードを介してループなしで到達できることを示します。ユニキャスト プレフィックス登録により、ノードは、ドメインで使用されているルーティング プロトコルに関係なく、別のルーティング ドメインでプレフィックスを再配布するように 1 つ以上の隣接ルータに要求できます。このドキュメントは、RFC 6550 および 9010 で規定されているように、低電力および損失の多いネットワーク (RPL) のルーティング プロトコルを更新し、6LoWPAN ルーター (6LR) が登録されたプレフィックスを RPL に挿入できるようにします。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9926.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9926 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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
2. Terminology
2.1. Requirements Language
2.2. Inherited Terms and Concepts
2.3. Acronyms and Initialisms
2.4. New Terms
3. Overview
4. Updating RFC 4861
5. Updating RFC 7400
6. Updating RFC 6550
7. Updating RFC 8505
7.1. New P-Field Value
7.2. New EARO Prefix Length Field and F flag
7.3. New EDAR Prefix Length Field
7.4. Updating the Registration Operation
8. Updating RFC 9010
9. Updating RFC 8928
10. Updating RFC 8929
11. Security Considerations
12. Operational Considerations
12.1. Partially Upgraded Networks
12.2. Application to RPL-Based Route-Over LLNs
12.3. Application to a Shared Link
12.4. Application to a Hub Link with Stub Spokes
13. IANA Considerations
13.1. Updated P-Field Registry
13.2. New 6LoWPAN Capability Bit
14. Normative References
15. Informative References
Acknowledgments
Author's Address
The design of Low Power and Lossy Networks (LLNs) is generally focused on saving energy, which is the most constrained resource of all. Other design constraints (such as a limited memory capacity, duty cycling of the LLN devices, and low-power lossy transmissions) derive from that primary concern. The radio (both transmitting or simply listening) is a major energy drain, and the LLN protocols must be adapted to allow the nodes to remain sleeping with the radio turned off at most times.
低電力および損失の多いネットワーク (LLN) の設計は、一般に、すべてのリソースの中で最も制約のあるエネルギーを節約することに焦点を当てています。他の設計上の制約 (メモリ容量の制限、LLN デバイスのデューティ サイクル、損失の多い低電力伝送など) は、この主な懸念から生じます。無線 (送信または単に受信の両方) は大きなエネルギー消費となるため、ほとんどの場合、無線をオフにしてノードがスリープ状態を維持できるように LLN プロトコルを適合させる必要があります。
Examples of LLNs include hub-and-spoke access links such as (Low-Power) Wi-Fi [IEEE80211] and Bluetooth (Low Energy) [IEEE802151], Mesh-Under networks where the routing operation is handled at Layer 2 (L2), and route-over networks such as the Wi-SUN [WI-SUN] and 6TiSCH [RFC9030] mesh networks, which leverage 6LoWPAN [RFC4919] [RFC6282] and RPL [RFC6550] over [IEEE802154].
LLN の例には、(低電力) Wi-Fi [IEEE80211] や Bluetooth (低エネルギー) [IEEE802151] などのハブアンドスポーク アクセス リンク、ルーティング操作がレイヤ 2 (L2) で処理されるメッシュアンダー ネットワーク、6LoWPAN を利用する Wi-SUN [WI-SUN] や 6TiSCH [RFC9030] メッシュ ネットワークなどのルートオーバー ネットワークが含まれます。[IEEE802154] 上の [RFC4919] [RFC6282] および RPL [RFC6550]。
LLNs and constrained devices are the original domain of application for 6LoWPAN protocols. It is thus a foremost concern, when designing those protocols, to minimize energy spendings. In non-LLN environments where lowering carbon emissions is also a priority, it could make sense to apply the 6LoWPAN designs and extend some of the 6LoWPAN protocols. The general design points include:
LLN と制約のあるデバイスは、6LoWPAN プロトコルのアプリケーションの元のドメインです。したがって、これらのプロトコルを設計する際の最優先事項は、エネルギー消費を最小限に抑えることです。二酸化炭素排出量の削減も優先事項である非 LLN 環境では、6LoWPAN 設計を適用し、6LoWPAN プロトコルの一部を拡張することが理にかなっている可能性があります。一般的な設計ポイントは次のとおりです。
* Placing the protocol complexity in the less-constrained routers to simplify the host implementation and avoid expanding the control traffic to all nodes.
* プロトコルの複雑さを制約の少ないルーターに配置して、ホストの実装を簡素化し、すべてのノードへの制御トラフィックの拡大を回避します。
* Using host-triggered operations to enable transient disconnections with the routers, e.g., to conserve power (sleep), but also to cope with inconsistent connectivity.
* ホストによってトリガーされる操作を使用して、ルーターとの一時的な切断を可能にし、電力を節約する (スリープ) だけでなく、一貫性のない接続にも対処します。
These points translate into:
これらの点は次のようになります。
* Stateful proactively built knowledge in the routers that is available at any point of time.
* ステートフルにより、ルーター内に事前に構築されたナレッジがいつでも利用可能になります。
* Unicast host-to-router operations triggered by the host and its applications.
* ホストとそのアプリケーションによってトリガーされる、ホストからルーターへのユニキャスト操作。
* Minimal use of asynchronous L2 broadcast operations that would keep the host awake and listening with no application-level need to do so.
* 非同期 L2 ブロードキャスト操作の使用を最小限に抑え、アプリケーション レベルで行う必要がなく、ホストを起動してリッスンし続けることができます。
"RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RFC6550] provides IPv6 [RFC8200] routing services within such constraints. To save signaling and routing state in constrained networks, the RPL routing is only performed along a Destination-Oriented Directed Acyclic Graph (DODAG) that is optimized to reach a Root node, as opposed to along the shortest path between two peers, whatever that would mean in each LLN.
「RPL: 低電力および損失の多いネットワークのための IPv6 ルーティング プロトコル」[RFC6550] は、そのような制約内で IPv6 [RFC8200] ルーティング サービスを提供します。制約のあるネットワークでシグナリングとルーティングの状態を保存するために、RPL ルーティングは、各 LLN でどのような意味になるかに関係なく、2 つのピア間の最短パスに沿ってではなく、ルート ノードに到達するように最適化された宛先指向有向非巡回グラフ (DODAG) に沿ってのみ実行されます。
The classical Neighbor Discovery Protocol (NDP) [RFC4861] [RFC4862] was defined for serial links and shared transit media such as Ethernet at a time when L2 broadcast was cheap on those media, while memory for neighbor cache was expensive. Thus, it was designed as a reactive protocol that relies on caching and multicast operations for the Duplicate Address Detection (DAD) and Address Resolution (AR), aka address discovery or address lookup, of IPv6 unicast addresses. Those multicast operations typically impact every node on-link when at most one is really targeted, which is a waste of energy, and imply that all nodes are awake to hear the request, which is inconsistent with power-saving (sleeping) modes.
古典的な近隣探索プロトコル (NDP) [RFC4861] [RFC4862] は、シリアル リンクおよびイーサネットなどの共有中継メディア向けに定義されました。当時、これらのメディアでは L2 ブロードキャストが安価でしたが、近隣キャッシュ用のメモリは高価でした。したがって、これは、IPv6 ユニキャスト アドレスの重複アドレス検出 (DAD) とアドレス解決 (AR)、別名アドレス検出またはアドレス検索のためのキャッシュとマルチキャスト操作に依存する反応型プロトコルとして設計されました。これらのマルチキャスト操作は、通常、実際にターゲットにされるのはせいぜい 1 つだけである場合に、リンク上のすべてのノードに影響を及ぼしますが、これはエネルギーの無駄であり、すべてのノードが要求を聞くために起きていることを意味し、これは省電力 (スリープ) モードと矛盾します。
"Architecture and Framework for IPv6 over Non-Broadcast Access" [IPv6-over-NBMA] introduces an evolution of IPv6 ND towards a proactive AR method. Because the IPv6 model for NBMA depends on a routing protocol to reach inside the subnet, the IPv6 ND extension for NBMA is referred to as Subnet Neighbor Discovery (SND). SND is based on work done in the context of Internet of Things (IoT), known as 6LoWPAN ND. As opposed to the classical IPv6 ND protocol, this evolution follows the energy conservation principles discussed above:
「非ブロードキャスト アクセスを介した IPv6 のアーキテクチャとフレームワーク」[IPv6-over-NBMA] では、プロアクティブな AR 方式に向けた IPv6 ND の進化が紹介されています。NBMA の IPv6 モデルはサブネット内に到達するためのルーティング プロトコルに依存するため、NBMA の IPv6 ND 拡張はサブネット近隣探索 (SND) と呼ばれます。SND は、6LoWPAN ND として知られるモノのインターネット (IoT) のコンテキストで行われる作業に基づいています。従来の IPv6 ND プロトコルとは対照的に、この進化は上で説明したエネルギー節約の原則に従います。
* The original 6LoWPAN ND, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775], was introduced to avoid the excessive use of multicast messages and enable IPv6 ND for operations over energy-constrained nodes. [RFC6775] changes the classical IPv6 ND model to proactively establish the Neighbor Cache Entry (NCE) associated to the unicast address of a 6LoWPAN Node (6LN) in the one or more 6LoWPAN Routers (6LRs) that serve it. To that effect, [RFC6775] defines a new Address Registration Option (ARO) that is placed in unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages between the 6LN and the 6LRs.
* オリジナルの 6LoWPAN ND、「低電力無線パーソナル エリア ネットワーク (6LoWPAN) 上の IPv6 の近隣探索最適化」[RFC6775] は、マルチキャスト メッセージの過剰な使用を回避し、エネルギーが制約されたノード上での運用に IPv6 ND を有効にするために導入されました。[RFC6775] は、古典的な IPv6 ND モデルを変更して、6LoWPAN ノード (6LN) にサービスを提供する 1 つ以上の 6LoWPAN ルーター (6LR) 内の 6LoWPAN ノード (6LN) のユニキャスト アドレスに関連付けられたネイバー キャッシュ エントリ (NCE) を積極的に確立します。その目的のために、[RFC6775] は、6LN と 6LR の間のユニキャスト近隣要請 (NS) および近隣広告 (NA) メッセージに配置される新しいアドレス登録オプション (ARO) を定義しています。
* "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery>" [RFC8505] updates [RFC6775] into a generic Address Registration mechanism and is the foundation for Subnet Neighbor Discovery (SND). SND introduces the Extended Address Registration Option (EARO) to enable the registering node to access services such as routing inside a subnet and ND proxy operations [RFC8929]. This provides a routing-protocol-agnostic method for a host to request that the router inject a unicast IPv6 address in the local routing protocol and provide return reachability for that address.
* 「低電力無線パーソナル エリア ネットワーク (6LoWPAN) 近隣探索を介した IPv6 の登録拡張機能>」 [RFC8505] は、[RFC6775] を汎用のアドレス登録メカニズムに更新し、サブネット近隣探索 (SND) の基盤となります。SND は、登録ノードがサブネット内のルーティングや ND プロキシ操作などのサービスにアクセスできるようにする拡張アドレス登録オプション (EARO) を導入しています [RFC8929]。これにより、ルータがローカル ルーティング プロトコルにユニキャスト IPv6 アドレスを挿入し、そのアドレスにリターン到達可能性を提供することをホストに要求するルーティング プロトコルに依存しない方法が提供されます。
* "Listener Subscription for IPv6 Neighbor Discovery Multicast and Anycast Addresses" [RFC9685] updates [RFC8505] to enable a listener to subscribe to an IPv6 anycast or multicast address; the document also updates [RFC9010] to enable a 6LR to inject the anycast and multicast addresses in RPL. Similarly, this specification updates [RFC8505] and [RFC9010] to add the capability for a 6LN to register unicast prefixes up to 120 bits long, as opposed to addresses, and to signal in a routing-protocol-independent fashion to a 6LR that it is expected to redistribute the prefixes.
* 「IPv6 近隣探索マルチキャストおよびエニーキャスト アドレスのリスナー サブスクリプション」[RFC9685] は、リスナーが IPv6 エニーキャスト アドレスまたはマルチキャスト アドレスにサブスクライブできるように [RFC8505] を更新します。この文書では、6LR が RPL にエニーキャスト アドレスとマルチキャスト アドレスを挿入できるようにするために [RFC9010] も更新されています。同様に、この仕様は [RFC8505] と [RFC9010] を更新し、6LN がアドレスではなく最大 120 ビット長のユニキャスト プレフィックスを登録し、ルーティング プロトコルに依存しない方法でプレフィックスの再配布が期待されていることを 6LR に通知する機能を追加します。
This specification updates the above registration and subscription methods to enable a node to register a unicast prefix to the routing system and get it injected in the routing protocol. As with [RFC8505], the prefix registration is agnostic to the routing protocol in which the router injects the prefix, and the router is agnostic to the method that was used to allocate the prefix to the node. The energy conservation principles in [RFC8505] are retained as well, meaning that the node does not have to send or expect asynchronous multicast messages.
この仕様では、ノードがルーティング システムにユニキャスト プレフィックスを登録し、それをルーティング プロトコルに挿入できるように、上記の登録およびサブスクリプション メソッドを更新します。[RFC8505] と同様、プレフィックスの登録は、ルータがプレフィックスを挿入するルーティング プロトコルに依存せず、ルータはノードにプレフィックスを割り当てるために使用された方法に依存しません。[RFC8505] のエネルギー節約原則も同様に維持されます。これは、ノードが非同期マルチキャスト メッセージを送信したり期待したりする必要がないことを意味します。
Please note that an energy-conserving node is not necessarily a router, so even when a node is advertising a prefix, it is a design choice not to use Router Advertisement (RA) messages that would make the node appear as a router to peer nodes. From the design principles above, it is clearly a design choice not to leverage (1) broadcasts from or to the node or (2) complex state machines in the node. It is also a design choice to use and extend the EARO as opposed to the Route Information Option (RIO) [RFC4191] because the RIO is not intended to inject routes in routing, and is lacking related control information like the R bit in the EARO. Additionally, an RA with RIO cannot be trusted for a safe injection in the routing protocol for the lack of the equivalent of the Registration Ownership Verifier (ROVR) [RFC8928] in the EARO.
エネルギー節約ノードは必ずしもルーターではないため、ノードがプレフィックスをアドバタイズしている場合でも、ノードをピア ノードに対してルーターとして見せるルーター アドバタイズメント (RA) メッセージを使用しないのは設計上の選択であることに注意してください。上記の設計原則から、(1) ノードからのブロードキャストまたはノードへのブロードキャスト、または (2) ノード内の複雑なステート マシンを利用しないのは明らかに設計上の選択です。RIO はルーティングにルートを挿入することを目的としておらず、EARO の R ビットのような関連する制御情報が不足しているため、ルート情報オプション (RIO) [RFC4191] ではなく EARO を使用および拡張することも設計上の選択です。さらに、EARO には Registration Ownership Verifier (ROVR) [RFC8928] に相当する機能がないため、RIO を備えた RA はルーティング プロトコルでの安全なインジェクションとして信頼できません。
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 terms and concepts that are discussed in:
このドキュメントでは、以下で説明されている用語と概念が使用されています。
* "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861] and
* 「IP バージョン 6 (IPv6) の近隣探索」[RFC4861] および
* "IPv6 Stateless Address Autoconfiguration" [RFC4862] for the Neighbor Solicitation operation,
* 近隣要請操作用の「IPv6 ステートレス アドレス自動設定」[RFC4862]、
* "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775], as well as
* 「低電力無線パーソナル エリア ネットワーク (6LoWPAN) 上の IPv6 の近隣探索最適化」[RFC6775]、および
* "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery" [RFC8505], and
* 「低電力無線パーソナル エリア ネットワーク (6LoWPAN) 近隣探索による IPv6 の登録拡張」 [RFC8505]、および
* "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RFC6550] for RPL, which is the routing protocol used in LLNs for SND.
* RPL の「RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks」[RFC6550]。SND の LLN で使用されるルーティング プロトコルです。
This document uses the following abbreviations:
このドキュメントでは次の略語を使用します。
6CIO:
6CIO:
6LoWPAN Capability Indication Option [RFC7400]
6LoWPAN能力表示オプション[RFC7400]
6LBR:
6LBR:
6LoWPAN Border Router [RFC6775]
6LoWPAN ボーダールーター [RFC6775]
6LN:
6LN:
6LoWPAN Node [RFC6775]
6LoWPANノード[RFC6775]
6LR:
6LR:
6LoWPAN Router [RFC6775]
6LoWPANルーター[RFC6775]
ARO:
アロ:
Address Registration Option [RFC6775]
アドレス登録オプション [RFC6775]
DAD:
お父さん：
Duplicate Address Detection [RFC4861]
重複アドレスの検出 [RFC4861]
DAO:
ダオ:
Destination Advertisement Object [RFC6550]
宛先アドバタイズメントオブジェクト [RFC6550]
DODAG:
ドダグ:
Destination-Oriented Directed Acyclic Graph
宛先指向の有向非巡回グラフ
EARO:
アーロ:
Extended Address Registration Option [RFC8505]
拡張アドレス登録オプション [RFC8505]
EDAC:
EDAC:
Extended Duplicate Address Confirmation [RFC8505]
拡張重複アドレス確認 [RFC8505]
EDAR:
エダル:
Extended Duplicate Address Request [RFC8505]
拡張重複アドレス要求 [RFC8505]
ESS:
ESS:
Extended Service Set [IEEE80211]
拡張サービスセット[IEEE80211]
IPAM:
IPAM:
IP Address Management
IPアドレス管理
LLN:
LLN:
Low-Power and Lossy Network
低電力で損失の多いネットワーク
LLA:
LLA:
Link-Layer Address
リンク層アドレス
LoWPAN:
ローパン:
Low-Power Wireless Personal Area Network
低電力ワイヤレスパーソナルエリアネットワーク
LR-WPAN:
LR-WPAN:
Low-Rate Wireless Personal Area Network [IEEE802154]
低速無線パーソナルエリアネットワーク [IEEE802154]
MAC:
マック：
Medium Access Control
媒体アクセス制御
NA:
NA:
Neighbor Advertisement (message) [RFC4861]
近隣広告（メッセージ） [RFC4861]
NBMA:
NBMA:
Non-Broadcast Multi-Access (full mesh)
非ブロードキャスト マルチアクセス (フルメッシュ)
NCE:
NCE:
Neighbor Cache Entry [RFC4861]
近隣キャッシュエントリ [RFC4861]
ND:
ND:
Neighbor Discovery (protocol)
近隣探索 (プロトコル)
NDP:
NDP:
Neighbor Discovery Protocol
近隣探索プロトコル
NS:
NS:
Neighbor Solicitation (message) [RFC4861]
近隣要請（メッセージ） [RFC4861]
ROVR:
ROVR:
Registration Ownership Verifier (pronounced "rover") [RFC8505]
登録所有権検証者 (「ローバー」と発音) [RFC8505]
RPL:
RPL:
IPv6 Routing Protocol for LLNs (pronounced "ripple") [RFC6550]
LLN 用の IPv6 ルーティング プロトコル (「リップル」と発音) [RFC6550]
RA:
ラ:
Router Advertisement (message) [RFC4861]
ルーターアドバタイズメント（メッセージ） [RFC4861]
RS:
RS:
Router Solicitation (message) [RFC4861]
ルーター要請（メッセージ） [RFC4861]
RTO:
RTO:
RPL Target Option [RFC6550]
RPLターゲットオプション[RFC6550]
SLLAO:
スラオ:
Source Link-Layer Address Option [RFC4861]
ソースリンク層アドレスオプション [RFC4861]
SND:
SND:
Subnet Neighbor Discovery (protocol)
サブネット近隣探索 (プロトコル)
TID:
TID:
Transaction ID [RFC8505]
トランザクションID [RFC8505]
TIO:
ティオ:
Transit Information Option [RFC6550]
交通情報オプション [RFC6550]
TLLAO:
トラオ:
Target Link-Layer Address Option [RFC4861]
ターゲットリンク層アドレスオプション [RFC4861]
This document introduces the following term:
このドキュメントでは次の用語が導入されています。
Origin:
起源：
The node that issued the prefix advertisement, either in the form of a NS(EARO) or as a DAO(TIO, RTO)
NS(EARO) の形式または DAO(TIO, RTO) としてプレフィックス アドバタイズメントを発行したノード
This specification inherits from [RFC6550], [RFC8505], and [RFC9010] to register prefixes as opposed to addresses.
この仕様は、アドレスではなくプレフィックスを登録するために [RFC6550]、[RFC8505]、および [RFC9010] を継承しています。
The IPv6 ND operation is agnostic to the routing protocol used in the SND. Route-over LLNs typically leverage RPL. A RPL-based SND deployment consists of:
IPv6 ND の動作は、SND で使用されるルーティング プロトコルに依存しません。ルートオーバー LLN は通常、RPL を利用します。RPL ベースの SND 導入は次のもので構成されます。
* one or more 6LBRs that act as RPL Root,
* RPL ルートとして機能する 1 つ以上の 6LBR、
* intermediate routers down the RPL graph that propagate routing information on addresses and prefixes towards the Root,
* RPL グラフの下にある中間ルーターは、アドレスとプレフィックスに関するルーティング情報をルートに伝播します。
* 6LRs that are RPL-aware 6LNs and can leverage RPL directly to expose their addresses and prefixes, and
* RPL 対応 6LN である 6LR は、RPL を直接活用してアドレスとプレフィックスを公開できます。
* 6LNs that are the RPL-unaware destinations and need SND to obtain reachability over the RPL LLN for their addresses and, with this specification, their prefixes as well.
* 6LN は RPL 非認識の宛先であり、そのアドレスと、この仕様ではプレフィックスも RPL LLN 経由で到達可能にするために SND を必要とします。
The SND operation for prefixes inherits from that for unicast addresses, meaning that it is the same unless specified otherwise herein. In particular, forwarding a packet happens as specified in Section 11 of [RFC6550], including loop avoidance and detection. However, in the case of multicast, multiple copies might be generated.
プレフィックスの SND 操作はユニキャスト アドレスの SND 操作を継承します。つまり、ここで特に指定しない限り、同じです。特に、パケットの転送は、ループの回避と検出を含め、[RFC6550] のセクション 11 で規定されているように行われます。ただし、マルチキャストの場合は、複数のコピーが生成される可能性があります。
[RFC8505] is a prerequisite to this specification. A node that implements this MUST also implement [RFC8505]. This specification does not introduce a new option; it modifies existing options and updates the associated behaviors to enable the registration for prefixes as an extension to [RFC8505].
[RFC8505] はこの仕様の前提条件です。これを実装するノードは [RFC8505] も実装しなければなりません (MUST)。この仕様は新しいオプションを導入するものではありません。既存のオプションを変更し、関連する動作を更新して、[RFC8505] の拡張機能としてプレフィックスの登録を可能にします。
This specification updates the P-Field introduced in [RFC9685] for use in EARO, DAR, and RTO, with the new value of 3 to indicate the registration of a prefix, as detailed in Section 7.2. With this extension, the 6LN can now express its willingness to receive the traffic for all addresses in the range of a prefix, using the P-Field value of 3 in the EARO to signal that the registration is for such prefix. Multiple 6LNs acting as border routers to the same external network or as access routers to the same subnet may register the same prefix to the same 6LR or to different 6LRs.
この仕様は、セクション 7.2 で詳述されているように、EARO、DAR、および RTO で使用するために [RFC9685] で導入された P フィールドを更新し、プレフィックスの登録を示す新しい値 3 を使用します。この拡張により、6LN は、EARO の P フィールド値 3 を使用して、プレフィックスの範囲内のすべてのアドレスのトラフィックを受信する意思を表明し、そのようなプレフィックスに対する登録であることを通知できるようになりました。同じ外部ネットワークへの境界ルータとして、または同じサブネットへのアクセス ルータとして機能する複数の 6LN は、同じ 6LR または異なる 6LR に同じプレフィックスを登録できます。
If the R flag is set in the registration of one or more 6LNs for the same prefix, then, according to its redistribution policy, the 6LR MUST redistribute the prefix in the routing protocol(s) (e.g., RPL) that it participates in. The duration of the redistribution is based on the longest registration lifetime across the non-expired received registrations for the prefix.`
同じプレフィックスに対する 1 つ以上の 6LN の登録で R フラグが設定されている場合、その再配布ポリシーに従って、6LR は参加するルーティング プロトコル (例: RPL) でプレフィックスを再配布しなければなりません。再配布の期間は、プレフィックスに対して期限切れになっていない受信した登録全体の最長の登録存続期間に基づきます。
Examples of use cases where this specification may apply include virtual links, shared links, and hub links as shown in Sections 12.3 and 12.4, respectively. More generally, the 6LN may be a router running a different routing protocol in an external network, e.g., a stub network, and acting as a border router. Using the prefix registration method enables decoupling the routing protocol in the 6LN from the routing protocol that the 6LRs run in the main LLN and provide signaling to stimulate the redistribution.
この仕様が適用されるユースケースの例には、それぞれセクション 12.3 および 12.4 に示すように、仮想リンク、共有リンク、およびハブ リンクが含まれます。より一般的には、6LN は、外部ネットワーク (スタブ ネットワークなど) で異なるルーティング プロトコルを実行し、境界ルータとして機能するルータであってもよい。プレフィックス登録方法を使用すると、6LN のルーティング プロトコルを、6LR がメイン LLN で実行し、再配布を刺激するシグナリングを提供するルーティング プロトコルから切り離すことができます。
[RFC4861] expects that the NS/NA exchange is for a unicast address, which is indicated in the Target Address field of the ND message. Section 5.5 of [RFC8505] extends [RFC4861] to signal the Registered Address in the Target Address field.
[RFC4861] は、NS/NA 交換がユニキャスト アドレスに対するものであることを期待しており、ユニキャスト アドレスは ND メッセージのターゲット アドレス フィールドに示されています。[RFC8505] のセクション 5.5 は、[RFC4861] を拡張して、ターゲット アドレス フィールドで登録アドレスを通知します。
This specification updates [RFC4861] by allowing a 6LN to advertise a prefix in the Target Address field when the NS or NA message is used for a registration, per Section 5.5 of [RFC8505]. In that case, the prefix length MUST be indicated in the EARO of the NS message, overloading the field that is used in the NA response for the Status.
この仕様は、[RFC8505] のセクション 5.5 に従って、登録に NS または NA メッセージが使用される場合に、6LN がターゲット アドレス フィールドでプレフィックスをアドバタイズできるようにすることで、[RFC4861] を更新します。その場合、プレフィックス長は NS メッセージの EARO で示され、ステータスの NA 応答で使用されるフィールドをオーバーロードしなければなりません。
If the 6LN owns at least one IPv6 address that is derived from the registered prefix with a non-zero interface ID, then it MUST indicate one of these addresses in full in the Target Address field of the NS(EARO) message. Else, it MUST indicate the prefix padded with zeros in the Target Address field.
6LN が、ゼロ以外のインターフェイス ID を持つ登録されたプレフィックスから導出された IPv6 アドレスを少なくとも 1 つ所有している場合、NS(EARO) メッセージのターゲット アドレス フィールドにこれらのアドレスの 1 つを完全に指定しなければなりません (MUST)。それ以外の場合は、ターゲットアドレスフィールドにゼロが埋め込まれたプレフィックスを示さなければなりません。
This specification updates "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC7400] by defining a new capability bit for use in the 6CIO. [RFC7400] was already extended by [RFC8505] for use in IPv6 ND messages.
この仕様は、6CIO で使用する新しい機能ビットを定義することにより、「6LoWPAN-GHC: 低電力無線パーソナル エリア ネットワーク (6LoWPAN) 上の IPv6 の汎用ヘッダー圧縮」[RFC7400] を更新します。[RFC7400] は、IPv6 ND メッセージで使用するために [RFC8505] によってすでに拡張されています。
The new "Registration for prefixes supported" (F) flag indicates to the 6LN that the 6LR (1) accepts IPv6 prefix registrations as specified in this document, (2) will ensure that packets for the addresses that match this prefix will be routed to the 6LNs that registered the prefix, and (3) will ensure that the route to the prefix will be redistributed if the R flag is set to 1.
新しい「サポートされるプレフィックスの登録」(F) フラグは、6LR が (1) この文書で指定されている IPv6 プレフィックス登録を受け入れること、(2) このプレフィックスに一致するアドレスのパケットがプレフィックスを登録した 6LN にルーティングされることを保証すること、および (3) R フラグが 1 に設定されている場合にプレフィックスへのルートが再配布されることを保証することを 6LN に示します。
Figure 1 illustrates the F flag in its position (16, counting 0 to 47 in network order in the 48-bit array).
図 1 は、F フラグの位置 (48 ビット配列のネットワーク順に 0 ～ 47 を数えて 16) を示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 1 | Experimental |X|A|D|L|B|P|E|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: New Capability Bit in the 6CIO
図 1: 6CIO の新しい機能ビット
New Option Field:
新しいオプションフィールド:
F:
F:
1-bit flag, set to 1 to indicate "Registration for prefixes supported"
1 ビットのフラグ。1 に設定すると、「プレフィックスの登録がサポートされている」ことを示します。
[RFC6550] uses the Path Sequence in the Transit Information Option (TIO) to retain only the freshest unicast route and remove stale ones, e.g., in the case of mobility. [RFC9010] copies the TID from the EARO into the Path Sequence, and the ROVR field into the associated RPL Target Option (RTO). This way, it is possible to identify both the registering node and the order of registration in RPL for each individual advertisement, so the most recent path and lifetime values are used.
[RFC6550] は、トランジット情報オプション (TIO) のパス シーケンスを使用して、最も新しいユニキャスト ルートのみを保持し、たとえばモビリティの場合に古いルートを削除します。[RFC9010] は、TID を EARO からパス シーケンスにコピーし、ROVR フィールドを関連する RPL ターゲット オプション (RTO) にコピーします。このようにして、個々のアドバタイズメントごとに登録ノードと RPL への登録順序の両方を識別できるため、最新のパスとライフタイムの値が使用されます。
[RFC9685] requires the use of the ROVR field as the indication of the origin of a Target advertisement in the RPL DAO messages, as specified in Section 6.1 of [RFC9010]. For anycast and multicast advertisements (in NS or DAO messages), multiple origins may subscribe to the same address, in which case the multiple advertisements from the different or unknown origins are merged by the common parent. In that case, the common parent becomes the origin of the merged advertisements and uses its own ROVR value. On the other hand, a parent that propagates an advertisement from a single origin uses the original ROVR in the propagated RTO, as it does for unicast address advertisements, so the origin is recognized across multiple hops.
[RFC9685] は、[RFC9010] のセクション 6.1 で規定されているように、RPL DAO メッセージ内のターゲット広告の発信元の表示として ROVR フィールドを使用することを要求しています。エニーキャストおよびマルチキャスト アドバタイズメント (NS または DAO メッセージ内) の場合、複数のオリジンが同じアドレスにサブスクライブする場合があります。この場合、異なるオリジンまたは未知のオリジンからの複数のアドバタイズメントは、共通の親によってマージされます。その場合、共通の親がマージされたアドバタイズメントの発信元となり、独自の ROVR 値を使用します。一方、単一オリジンからアドバタイズメントを伝播する親は、ユニキャスト アドレス アドバタイズメントの場合と同様に、伝播された RTO で元の ROVR を使用するため、オリジンは複数のホップにわたって認識されます。
This specification updates [RFC6550] to require that, for prefix routes, the Path Sequence is used between and only between advertisements for the same Target and from the same origin (i.e., with the same ROVR value); in that case, only the freshest advertisement is retained. However, the freshness comparison cannot apply if the origin is not determined (i.e., the origin did not support this specification).
この仕様は [RFC6550] を更新し、プレフィックス ルートの場合、パス シーケンスが、同じターゲットおよび同じオリジンからの（つまり、同じ ROVR 値を持つ）広告間でのみ使用されることを要求します。その場合、最も新しいアドバタイズメントのみが保持されます。ただし、オリジンが特定されていない場合 (つまり、オリジンがこの仕様をサポートしていなかった場合)、鮮度の比較は適用できません。
[RFC6550] uses the Path Lifetime in the TIO to indicate the remaining time for which the advertisement is valid for unicast route determination, and a Path Lifetime value of 0 invalidates that route. [RFC9010] maps the Address Registration lifetime in the EARO and the Path Lifetime in the TIO so they are comparable when both forms of advertisements are received.
[RFC6550] は、TIO のパス ライフタイムを使用して、ユニキャスト ルート決定に広告が有効である残り時間を示します。パス ライフタイム値 0 は、そのルートを無効にします。[RFC9010] は、EARO のアドレス登録ライフタイムと TIO のパスライフタイムをマッピングして、両方の形式のアドバタイズメントを受信した場合にそれらを比較できるようにしています。
The RPL router that merges multiple advertisements for the same prefix MUST use and advertise the longest remaining lifetime across all the origins of the advertisements for that prefix. When the lifetime expires, the router sends a no-path DAO message (i.e., the lifetime is 0) using the same value for the ROVR value as for the previous advertisements. This value refers to either the single descendant that advertised the Target if there is only one or the router itself if there is more than one.
同じプレフィックスに対する複数のアドバタイズメントをマージする RPL ルーターは、そのプレフィックスに対するアドバタイズメントのすべての発信元にわたる最長の残りのライフタイムを使用してアドバタイズしなければなりません (MUST)。有効期限が切れると、ルータは、以前のアドバタイズメントと同じ ROVR 値を使用して、パスなし DAO メッセージ (つまり、有効期限が 0) を送信します。この値は、ターゲットが 1 つしかない場合はそのターゲットをアドバタイズした 1 つの子孫、または複数ある場合はルーター自体を指します。
Note that the Registration Lifetime, TID, and ROVR fields are also placed in the EDAR message, so the state created by EDAR is also comparable with that created upon an NS(EARO) or a DAO message. For simplicity, the text below mentions only NS(EARO) but it also applies to EDAR.
登録ライフタイム、TID、および ROVR フィールドも EDAR メッセージに配置されるため、EDAR によって作成される状態は、NS(EARO) または DAO メッセージで作成される状態と同等であることに注意してください。わかりやすくするために、以下のテキストでは NS(EARO) についてのみ言及していますが、EDAR にも適用されます。
This specification updates the EARO and EDAR messages to enable the registration of prefixes and updates the registration operation in the case of a prefix, in particular from the standpoint of the 6LR, e.g., to enable the registration of overlapping prefixes.
この仕様は、プレフィックスの登録を可能にするために EARO および EDAR メッセージを更新し、特に 6LR の観点から、プレフィックスの場合の登録操作を更新します (例えば、重複するプレフィックスの登録を可能にする)。
[RFC9685] defines a 2-bit P-Field with values 0 through 2 and reserves the value 3 for future use. This specification defines the semantics of P-Field value 3.
[RFC9685] は、値 0 ～ 2 を持つ 2 ビット P フィールドを定義し、値 3 を将来の使用のために予約します。この仕様は、P フィールド値 3 のセマンティクスを定義します。
When the P-Field is set to 3, it indicates that the Registered Address represents a prefix rather than a single address. Upon receiving an NS(EARO) message with the P-Field set to 3, the receiver MUST install a route to the indicated prefix via the source address of the NS(EARO) message.
P フィールドが 3 に設定されている場合、登録アドレスが単一のアドレスではなくプレフィックスを表すことを示します。P フィールドが 3 に設定された NS(EARO) メッセージを受信した場合、受信者は、NS(EARO) メッセージの送信元アドレスを介して、指定されたプレフィックスへのルートをインストールしなければなりません (MUST)。
This specification assigns the value 3 to the P-Field, resulting in the following complete set of defined values:
この仕様では値 3 を P フィールドに割り当て、その結果、次の完全な定義値セットが得られます。
+=======+======================================+
| Value | Meaning |
+=======+======================================+
| 0 | Registration for a Unicast Address |
+-------+--------------------------------------+
| 1 | Registration for a Multicast Address |
+-------+--------------------------------------+
| 2 | Registration for an Anycast Address |
+-------+--------------------------------------+
| 3 | Registration for a Unicast Prefix |
+-------+--------------------------------------+
Table 1: P-Field Values
表 1: P フィールド値
Section 4.1 of [RFC8505] defines the EARO as an extension to the ARO option defined in [RFC6775].
[RFC8505] のセクション 4.1 では、EARO を [RFC6775] で定義された ARO オプションの拡張として定義しています。
The Status field is used only when the EARO is placed in an NA message. This specification repurposes that field to carry the prefix length when the EARO is placed in an NS message as illustrated in Figure 2. The prefix length is expressed as 7 bits, and the most significant bit of the field is reserved. A 7-bit value of 0 is understood as a truncated 128, meaning that this registration is for an address as opposed to a prefix. This approach is backward compatible with [RFC8505] and spans both addresses and prefixes.
Status フィールドは、EARO が NA メッセージに配置される場合にのみ使用されます。この仕様では、図 2 に示すように、EARO が NS メッセージに配置されるときに、そのフィールドをプレフィックス長を伝送するために再利用します。プレフィックス長は 7 ビットで表され、フィールドの最上位ビットは予約されています。7 ビット値 0 は切り捨てられた 128 として理解され、この登録はプレフィックスではなくアドレスに対するものであることを意味します。このアプローチは [RFC8505] と下位互換性があり、アドレスとプレフィックスの両方に適用されます。
This specification adds a new F flag to signal that the Registered Prefix is topologically correct through the Registering Node. This means that the Registering Node relays packets that are sourced in the Registered Prefix to the outside, in accordance with "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing" [BCP38]. The receiver forwards packets to the Registering Node address when the source address of the packets derives from the Registered Prefix. Note that to avoid loops, the receiver must be in the inside so packets sent by the sender towards the outside may never reach the receiver. The notion of "inside" and "outside" are administratively defined, e.g., "inside" is a particular L2 network such as an Ethernet fabric.
この仕様では、登録ノードを通じて登録プレフィックスがトポロジー的に正しいことを通知する新しい F フラグが追加されています。これは、「ネットワークイングレスフィルタリング: IP ソースアドレススプーフィングを使用するサービス拒否攻撃の阻止」[BCP38] に従って、登録ノードが登録プレフィックスを送信元とするパケットを外部に中継することを意味します。パケットの送信元アドレスが登録済みプレフィックスから派生する場合、受信者はパケットを登録ノード アドレスに転送します。ループを回避するには、送信者から外部に送信されたパケットが受信者に到達しないように、受信者が内部にいる必要があることに注意してください。「内部」と「外部」の概念は管理的に定義されます。たとえば、「内部」はイーサネット ファブリックなどの特定の L2 ネットワークです。
When the F flag is not set, the Registering Node owns the prefix and will deliver packets to the destination if the destination address derives from the prefix. Conversely, if the F flag is set, the Registering Node will forward traffic whose source address derives from the Registered Prefix into a network location (e.g., to an ISP Provider Edge) where this source address is topologically correct (e.g., derives from a prefix assigned by that ISP). The F flag is encoded in the most significant bit of the EARO Status field when the Status field is used to transport a Prefix Length as shown in Figure 2.
F フラグが設定されていない場合、登録ノードはプレフィックスを所有し、宛先アドレスがプレフィックスから派生する場合は宛先にパケットを配信します。逆に、F フラグが設定されている場合、登録ノードは、送信元アドレスが登録プレフィックスから派生するトラフィックを、この送信元アドレスがトポロジー的に正しい (たとえば、その ISP によって割り当てられたプレフィックスから派生する) ネットワーク ロケーション (たとえば、ISP プロバイダー エッジ) に転送します。図 2 に示すように、ステータス フィールドがプレフィックス長の転送に使用される場合、F フラグは EARO ステータス フィールドの最上位ビットにエンコードされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |F|Prefix Length| Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|r|C| P | I |R|T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ROVR ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: EARO Format for Use in NS Messages
図 2: NS メッセージで使用する EARO 形式
New and updated Option Fields:
新規および更新されたオプション フィールド:
F: (Forwarding Flag)
F: (転送フラグ)
A 1-bit flag. When set to 1, it indicates that the sender expects other routers to forward packets to the sender when those packets are sourced from within the registered prefix.
1 ビットのフラグ。1 に設定すると、パケットが登録されたプレフィックス内から送信された場合、送信者は他のルーターがパケットを送信者に転送することを期待していることを示します。
Prefix Length:
プレフィックスの長さ:
A 7-bit unsigned integer. When the P-Field is set to 3 and the EARO is included in an NS message, this field MUST contain a prefix length expressed in bits, with a value in the inclusive range of 16 to 120. When the EARO is included in an NA message, this field MUST carry a status value, regardless of the setting of the P-Field. In all other cases, this field is reserved; it MUST be set to zero by the sender and MUST be ignored by the receiver.
7 ビットの符号なし整数。P フィールドが 3 に設定され、EARO が NS メッセージに含まれる場合、このフィールドには、16 から 120 の範囲の値を持つビットで表されるプレフィックス長が含まれなければなりません (MUST)。 EARO が NA メッセージに含まれる場合、このフィールドは、P フィールドの設定に関係なく、ステータス値を伝送しなければなりません (MUST)。それ以外の場合はすべて、このフィールドは予約されています。送信者はゼロに設定しなければならず、受信者は無視しなければなりません。
r (reserved):
r (予約済み):
A 1-bit reserved field. It MUST be set to zero by the sender and MUST be ignored by the receiver.
1 ビットの予約フィールド。送信者はゼロに設定しなければならず、受信者は無視しなければなりません。
This specification adds the new value of 3 to the P-Field to signal that the Registered Address is a prefix. When that is the case, the prefix is assumed to be at most 120 bits long, padded with zeros up to 120 bits, and the remaining byte is dedicated to one reserved bit and the Prefix Length.
この仕様では、新しい値 3 を P フィールドに追加して、登録アドレスがプレフィックスであることを示します。この場合、プレフィックスの長さは最大 120 ビットとみなされ、最大 120 ビットまでゼロが埋め込まれ、残りのバイトは 1 つの予約ビットとプレフィックス長専用になります。
Figure 3 illustrates the EDAR message when the value of the P-Field is 3. Figure 4 shows the response EDAC message, with the Status field and the echoed Prefix.
図 3 は、P フィールドの値が 3 の場合の EDAR メッセージを示しています。図 4 は、ステータス フィールドとエコーされたプレフィックスを含む応答 EDAC メッセージを示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |CodePfx|CodeSfx| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P=3| Reserved | TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ROVR ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Prefix +
| |
+ (up to 120 bits, padded with zeros) +
| |
+ +-+-+-+-+-+-+-+-+
| |r|Prefix Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 3: EDAR Message Format with P == 3
図 3: P == 3 の EDAR メッセージ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |CodePfx|CodeSfx| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ROVR ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Prefix +
| |
+ (up to 120 bits, padded with zeros) +
| |
+ +-+-+-+-+-+-+-+-+
| |r|Prefix Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 4: EDAC Message Format
図 4: EDAC メッセージのフォーマット
New and updated EDAR/EDAC Message Fields:
新規および更新された EAR/EDAC メッセージ フィールド:
Prefix:
プレフィックス:
A 15-byte field that carries up to 120 bits of the prefix. If the prefix is shorter than 120 bits, the remaining bits MUST be padded with zeros. The receiver MUST treat the padding as zeroed and MUST overwrite any unused bits with zeros before using the prefix.
最大 120 ビットのプレフィックスを伝送する 15 バイトのフィールド。プレフィックスが 120 ビットより短い場合、残りのビットはゼロで埋められなければなりません。受信者は、パディングをゼロ化されたものとして扱わなければならず、プレフィックスを使用する前に、未使用のビットをゼロで上書きしなければなりません。
r (reserved):
r (予約済み):
A 1-bit reserved field. It MUST be set to zero by the sender and MUST be ignored by the receiver.
1 ビットの予約フィールド。送信者はゼロに設定しなければならず、受信者は無視しなければなりません。
Prefix Length:
プレフィックスの長さ:
A 7-bit unsigned integer indicating the length of the prefix in bits. The value MUST be in the inclusive range of 16 to 120.
プレフィックスの長さをビット単位で示す 7 ビットの符号なし整数。値は 16 ～ 120 の範囲内である必要があります。
The capability to place the P-Field and the contiguous "Reserved" field in the EDAR message is specified in Section 7.2 of [RFC9685].
EDAR メッセージに P フィールドと連続する「予約」フィールドを配置する機能は、[RFC9685] のセクション 7.2 で指定されています。
The capability to append ND options to the EDAR and EDAC messages is introduced in Section 3.1 of [RFC8929].
EDAR および EDAC メッセージに ND オプションを追加する機能は、[RFC8929] のセクション 3.1 で導入されています。
All other fields follow the same definition as specified in [RFC8505]. The values for these fields and RFC references are maintained by IANA under the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" [IANA.ICMP] registry group.
他のすべてのフィールドは、[RFC8505] で指定されているのと同じ定義に従います。これらのフィールドの値と RFC 参照は、IANA によって「インターネット コントロール メッセージ プロトコル バージョン 6 (ICMPv6) パラメーター」[IANA.ICMP] レジストリ グループで管理されます。
With [RFC8505]:
[RFC8505] の場合:
* A router that expects to reboot may send a final RA message, upon which nodes should register elsewhere or redo the registration to the same router upon reboot. In all other cases, a node reboot is silent. When the node comes back to life, existing registration state might be lost if it was not safely stored, e.g., in persistent memory.
* 再起動を予期するルータは、最終 RA メッセージを送信することがあり、これに基づいてノードは別の場所に登録するか、再起動時に同じルータへの登録をやり直す必要があります。それ以外の場合はすべて、ノードの再起動はサイレントで行われます。ノードが復旧したときに、永続メモリなどに安全に保存されていなかった場合、既存の登録状態が失われる可能性があります。
* Only unicast addresses can be registered.
* ユニキャストアドレスのみ登録可能です。
* The 6LN must register all its Unique Local Addresses (ULAs) and Global Unicast Addresses (GUAs) with a NS(EARO).
* 6LN は、すべての固有ローカル アドレス (ULA) とグローバル ユニキャスト アドレス (GUA) を NS(EARO) に登録する必要があります。
* The 6LN may set the R flag in the EARO to obtain return reachability services from the 6LR, e.g., through ND proxy operations or by injecting the route in a route-over subnet.
* 6LN は、EARO に R フラグを設定して、たとえば ND プロキシ操作を通じて、またはルートオーバー サブネットにルートを挿入することによって、6LR からリターン到達可能性サービスを取得できます。
* The 6LR maintains a registration state per Registered Address, including an NCE with the Link Layer Address (LLA) of the Registered Node (the 6LN here).
* 6LR は、登録ノード (ここでは 6LN) のリンク層アドレス (LLA) を持つ NCE を含む、登録アドレスごとの登録状態を維持します。
The operation for registering prefixes is similar to that for addresses from the perspective of the 6LN, but shows important differences on the router side, which maintains a separate state for each origin and merges them in its own advertisements. This specification adds the following behavior, similar to that introduced by [RFC9685] for multicast addresses:
プレフィックスを登録する操作は、6LN の観点からはアドレスの操作と似ていますが、ルーター側で重要な違いが見られます。ルータ側では、オリジンごとに個別の状態を維持し、それらを独自のアドバタイズメントにマージします。この仕様では、マルチキャスト アドレスに対して [RFC9685] で導入されたものと同様の、次の動作が追加されます。
* The EARO status indicating a "Registration Refresh Request" applies to prefixes as well.
* 「登録更新要求」を示す EARO ステータスは、プレフィックスにも適用されます。
This status is used in asynchronous NA(EARO) messages to indicate to peer 6LNs that they are requested to reregister all addresses and prefixes that were previously registered to the originating node. The NA message MAY be sent to a unicast or a multicast link-scope address and SHOULD be contained within the L2 range where nodes may effectively have registered/subscribed to this router, e.g., a radio broadcast domain to preserve energy and spectrum.
このステータスは、発信元ノードに以前に登録されたすべてのアドレスとプレフィックスを再登録するように要求されていることをピア 6LN に示すために、非同期 NA(EARO) メッセージで使用されます。NA メッセージは、ユニキャストまたはマルチキャストのリンクスコープ アドレスに送信されてもよく、ノードが効果的にこのルータに登録/加入している可能性がある L2 範囲内 (エネルギーとスペクトルを保存するための無線ブロードキャスト ドメインなど) 内に含めるべきです (SHOULD)。
A device that wishes to refresh its state, e.g., upon reboot if it may have lost some registration state, SHOULD send an asynchronous NA(EARO) with this new status value. That asynchronous NA(EARO) SHOULD be sent to the all-nodes link-scope multicast address (ff02::1), and Target MUST be set to the link-local address that was exposed previously by this node to accept registrations, and the TID MUST be set to 0; the ROVR field MUST be set to all zeros and ignored by the receiver.
状態を更新したいデバイスは、たとえば、登録状態が失われた可能性がある場合の再起動時に、この新しいステータス値を含む非同期 NA(EARO) を送信すべきです(SHOULD)。その非同期 NA(EARO) は、全ノードのリンクスコープ マルチキャスト アドレス (ff02::1) に送信されるべきであり、ターゲットは、登録を受け入れるためにこのノードによって以前に公開されたリンクローカル アドレスに設定されなければならず、TID は 0 に設定されなければなりません。ROVR フィールドはすべて 0 に設定され、受信機によって無視されなければなりません (MUST)。
In an environment with unreliable transmissions, the multicast NA(EARO) message may be resent in a fast sequence, in which case the TID is incremented each time. A 6LN that has recently processed the NA(EARO) indicating a "Registration Refresh Request" ignores the additional NA(EARO) also indicating a "Registration Refresh Request" within the duration of the fast sequence. That duration depends on the environment and has to be configured. By default, it is 10 seconds.
送信の信頼性が低い環境では、マルチキャスト NA(EARO) メッセージが高速シーケンスで再送信される可能性があり、その場合、TID は毎回インクリメントされます。「登録リフレッシュ要求」を示す NA(EARO) を最近処理した 6LN は、高速シーケンスの持続時間内に、同様に「登録リフレッシュ要求」を示す追加の NA(EARO) を無視します。その期間は環境によって異なるため、構成する必要があります。デフォルトでは 10 秒です。
* Registration for prefixes is now supported. The value of 3 in the P-Field of the EARO and the EDAR message signals when the registration is for a prefix as opposed to an address. DAD for prefixes and addresses becomes a prefix overlap match. Whether overlapping addresses and prefixes may be registered is a network policy decision and out of scope. The same prefix may be injected twice (multiple routes) as long as they use the same value of the ROVR.
* プレフィックスの登録がサポートされるようになりました。EARO および EDAR メッセージの P フィールドの値 3 は、登録がアドレスではなくプレフィックスに対するものであることを示します。プレフィックスとアドレスの DAD はプレフィックスの重複一致になります。重複するアドレスとプレフィックスを登録できるかどうかはネットワーク ポリシーの決定であり、範囲外です。同じ ROVR の値を使用する限り、同じプレフィックスを 2 回（複数のルート）挿入できます。
Overlaps may be desirable. For instance, it may happen that a router or a proxy (see Section 10) registers a prefix or an aggregation while a host using an address from that prefix or a prefix from that aggregation also registers its piece.
重複することが望ましい場合があります。たとえば、ルーターまたはプロキシ (セクション 10 を参照) がプレフィックスまたは集合体を登録する一方で、そのプレフィックスまたは集合体からのプレフィックスのアドレスを使用するホストもその部分を登録することが発生する可能性があります。
In case of an overlapping registration, the longest prefix match wins, meaning that if the network policy allows for overlapping registrations, then the routes for the registered prefixes are installed towards the node that registered with the longest prefix match, all the way to /128.
重複する登録の場合、最も長いプレフィックス一致が優先されます。つまり、ネットワーク ポリシーで重複登録が許可されている場合、登録されたプレフィックスのルートは、最も長いプレフィックス一致で登録されたノードに向けて、/128 までインストールされます。
* If the 6LR acts as a border router to external prefixes or owns the prefixes entirely, it SHOULD register all those prefixes on all interfaces from which it might be needed to relay traffic to that prefix. It MUST set the P-Field in the EARO to 3 for those prefixes and set the R flag to receive the traffic associated to the prefixes. It MAY refrain from registering a prefix on one interface if that prefix is already successfully registered on another interface, or the router handled the EDAR/EDAC flow by itself, to ensure that the prefix ownership is known and validated by the 6LBR. Additionally, if the router expects to receive traffic for that prefix on that interface, it needs to ensure that the prefix is advertised some other way, e.g., over a routing protocol such as RPL.
* 6LR が外部プレフィックスへの境界ルータとして機能するか、プレフィックスを完全に所有している場合、そのプレフィックスへのトラフィックの中継に必要となる可能性があるすべてのインターフェイスにそれらすべてのプレフィックスを登録すべきです (SHOULD)。これらのプレフィックスに対して EARO の P フィールドを 3 に設定し、プレフィックスに関連付けられたトラフィックを受信するために R フラグを設定しなければなりません。プレフィックスの所有権が 6LBR によって認識され検証されていることを確認するために、そのプレフィックスがすでに別のインターフェイスに正常に登録されている場合、またはルーターが独自に EAR/EDAC フローを処理した場合、あるインターフェイスでのプレフィックスの登録を控えてもよい(MAY)。さらに、ルーターがそのインターフェイスでそのプレフィックスのトラフィックを受信することを期待している場合は、そのプレフィックスが別の方法 (たとえば、RPL などのルーティング プロトコル経由) でアドバタイズされることを確認する必要があります。
* The 6LN MAY set the R flag in the EARO to request the 6LR to redistribute the prefix on other links using a routing protocol. The 6LR MUST NOT reregister that prefix to yet another router unless loops are avoided some way, e.g., following a tree structure.
* 6LN は、EARO に R フラグを設定して、ルーティング プロトコルを使用して他のリンクにプレフィックスを再配布するように 6LR に要求してもよい(MAY)。6LR は、ループが何らかの方法で回避される (たとえばツリー構造に従うなど) 場合を除き、そのプレフィックスをさらに別のルータに再登録してはなりません (MUST NOT)。
* The 6LR and the 6LBR are extended to accept more than one registration for the same prefix, since multiple 6LNs may register it. The ROVR in the EARO identifies uniquely a registration within the namespace of the Registered Prefix.
* 6LR と 6LBR は、複数の 6LN が登録できるため、同じプレフィックスに対する複数の登録を受け入れるように拡張されています。EARO の ROVR は、登録済みプレフィックスの名前空間内の登録を一意に識別します。
* The 6LR MUST maintain a registration state per tuple (IPv6 prefix, prefix length, ROVR) for all registered prefixes. It SHOULD notify the 6LBR with an EDAR message, unless it determined that the 6LBR is legacy and does not support this specification (see Section 5). In turn, the 6LBR MUST maintain a registration state per tuple (IPv6 prefix, ROVR) for all prefixes.
* 6LR は、登録されているすべてのプレフィックスについて、タプルごとの登録状態 (IPv6 プレフィックス、プレフィックス長、ROVR) を維持しなければなりません (MUST)。6LBR がレガシーであり、この仕様をサポートしていないと判断しない限り、6LBR に EDAR メッセージを通知する必要があります (セクション 5 を参照)。次に、6LBR はすべてのプレフィックスのタプル (IPv6 プレフィックス、ROVR) ごとに登録状態を維持しなければなりません (MUST)。
With [RFC9010]:
[RFC9010] の場合:
* The 6LR injects only unicast routes in RPL.
* 6LR は、RPL にユニキャスト ルートのみを挿入します。
* Upon a registration with the R flag set to 1 in the EARO, the 6LR injects the address in the RPL unicast support.
* EARO で R フラグを 1 に設定して登録すると、6LR は RPL ユニキャスト サポートにアドレスを挿入します。
* Upon receiving a packet directed to a unicast address for which it has an active registration, the 6LR delivers the packet as a unicast L2 frame to the LLA of the node that registered the unicast address.
* 6LR は、アクティブな登録があるユニキャスト アドレス宛てのパケットを受信すると、そのパケットをユニキャスト L2 フレームとして、ユニキャスト アドレスを登録したノードの LLA に配信します。
This specification adds the following behavior:
この仕様により、次の動作が追加されます。
* Upon a registration with the R flag set to 1 and the P-Field set to 3 in the EARO, the 6LR injects the prefix in RPL using a prefix RTO. The P-Field in the RTP MUST be set to 3.
* EARO で R フラグを 1 に設定し、P フィールドを 3 に設定して登録すると、6LR はプレフィックス RTO を使用して RPL にプレフィックスを挿入します。RTP の P フィールドは 3 に設定する必要があります。
* Upon receiving a packet directed to an address that derives from a prefix for which it has at least one registration, the 6LR delivers a copy of the packet as a unicast L2 frame to the LLA of exactly one of the nodes that registered to that prefix, using the longest prefix match derivation to find the best 6LN.
* 6LR は、少なくとも 1 つの登録があるプレフィックスから派生したアドレス宛てのパケットを受信すると、最長プレフィックス一致導出を使用して最適な 6LN を見つけ、パケットのコピーをユニキャスト L2 フレームとしてそのプレフィックスに登録されたノードの 1 つの LLA に配信します。
"Address-Protected Neighbor Discovery for Low-Power and Lossy Networks" [RFC8928] was defined to protect the ownership of unicast IPv6 addresses that are registered with [RFC8505].
「低電力および損失の多いネットワークのためのアドレス保護された近隣探索」[RFC8928] は、[RFC8505] に登録されたユニキャスト IPv6 アドレスの所有権を保護するために定義されました。
With Address-Protected Neighbor Discovery (AP-ND) [RFC8928], it is possible for a node to autoconfigure a pair of public and private keys and use them to sign the registration of addresses that are either autoconfigured or obtained through other methods.
Address-Protected Neighbor Discovery (AP-ND) [RFC8928] を使用すると、ノードが公開鍵と秘密鍵のペアを自動構成し、それらを使用して、自動構成されたアドレスまたは他の方法で取得されたアドレスの登録に署名することができます。
The first-hop router (the 6LR) can then validate a registration and perform source address validation on packets coming from the sender node (the 6LN).
その後、ファーストホップ ルーター (6LR) は登録を検証し、送信側ノード (6LN) からのパケットに対して送信元アドレス検証を実行できます。
As multiple nodes may register the same prefix, the method specified in [RFC8928] cannot be used with node-local autoconfigured keypairs, which protect a single ownership only.
複数のノードが同じプレフィックスを登録する可能性があるため、[RFC8928] で指定されている方法は、単一の所有権のみを保護するノードローカルの自動構成キーペアでは使用できません。
For a prefix, as for an anycast or a multicast address, it is still possible to leverage AP-ND [RFC8928] to enforce the right to register. If AP-ND [RFC8928] is used, a keypair MUST be created and associated with the prefix before the prefix is deployed, and a ROVR MUST be generated from that keypair as specified in [RFC8928]. The prefix and the ROVR MUST then be installed in the 6LBR at the first registration, or by an external mechanism such as IP Address Management (IPAM) or DHCPv6 snooping prior to the first registration. This way, the 6LBR can recognize the prefix on the future registrations and validate the right to register based on the ROVR.
プレフィックスについては、エニーキャスト アドレスやマルチキャスト アドレスと同様に、AP-ND [RFC8928] を利用して登録する権利を強制することが可能です。AP-ND [RFC8928] が使用される場合、プレフィックスが展開される前にキーペアが作成され、プレフィックスに関連付けられなければなりません (MUST)。また、[RFC8928] で指定されているように、そのキーペアから ROVR が生成されなければなりません。プレフィックスと ROVR は、最初の登録時に 6LBR にインストールするか、最初の登録の前に IP アドレス管理 (IPAM) や DHCPv6 スヌーピングなどの外部メカニズムによってインストールする必要があります。このようにして、6LBR は将来の登録のプレフィックスを認識し、ROVR に基づいて登録する権利を検証できます。
The keypair MUST then be provisioned in each node that needs to register the prefix or a prefix within, so the node can follow the steps in [RFC8928] to register the prefix.
次に、ノードが [RFC8928] の手順に従ってプレフィックスを登録できるように、プレフィックスまたはその内部のプレフィックスを登録する必要がある各ノードにキーペアをプロビジョニングしなければなりません (MUST)。
Upon receiving an NA message with the status set to 5 "Validation Requested", the node that registered the address or prefix performs the proof of ownership based on that longest prefix match.
ステータスが 5「検証要求済み」に設定された NA メッセージを受信すると、アドレスまたはプレフィックスを登録したノードは、その最長のプレフィックス一致に基づいて所有権の証明を実行します。
"IPv6 Backbone Router" [RFC8929] defines a proxy operation whereby a 6LoWPAN Border Router (6LBR) may impersonate a 6LN when performing an address registration. In that case, [RFC8505] messages are used as is, with one change that the SLLAO in the proxied NS(EARO) messages indicates the Registering Node (the 6LBR) as opposed to the Registered Node (the 6LN). See Figure 5 of [RFC8929] for an example of proxy operation by the 6LBR, which generates an NS(EARO) upon receiving an EDAR message.
「IPv6 バックボーン ルータ」[RFC8929] は、アドレス登録を実行するときに 6LoWPAN ボーダー ルータ (6LBR) が 6LN になりすますプロキシ動作を定義しています。その場合、[RFC8505] メッセージはそのまま使用されますが、プロキシされた NS(EARO) メッセージ内の SLLAO が登録ノード (6LN) ではなく登録ノード (6LBR) を示すという 1 つの変更があります。EDAR メッセージの受信時に NS(EARO) を生成する 6LBR によるプロキシ動作の例については、[RFC8929] の図 5 を参照してください。
This specification updates that proxy operation with the updates in [RFC9685] and defines the formats and content of the EARO, EDAR, and EDAC messages in order to support the P-Field and the signaling of prefixes. The proxy MUST use the P-Field as received in the EDAR or NS(EARO) message to generate the proxied NS(EARO), and it MUST use the exact same prefix and prefix length as received in the case of a prefix registration.
この仕様は、[RFC9685] の更新でプロキシ動作を更新し、P フィールドとプレフィックスのシグナリングをサポートするために EARO、EDAR、および EDAC メッセージの形式と内容を定義します。プロキシは、プロキシされた NS(EARO) を生成するために、EDAR または NS(EARO) メッセージで受信した P フィールドを使用しなければなりません (MUST)。また、プレフィックス登録の場合に受信したものとまったく同じプレフィックスとプレフィックス長を使用しなければなりません (MUST)。
This specification updates [RFC8505], and the security considerations of that document also apply to this document. In particular, the link layer SHOULD be sufficiently protected to prevent rogue access, else a rogue node with physical access to the network may inject packets and perform an attack from within.
この仕様は [RFC8505] を更新しており、その文書のセキュリティに関する考慮事項はこの文書にも適用されます。特に、リンク層は不正アクセスを防止するために十分に保護される必要があります。そうしないと、ネットワークに物理的にアクセスする不正ノードがパケットを注入し、内部から攻撃を実行する可能性があります。
Section 9 leverages AP-ND [RFC8928] to prevent a rogue node from registering a unicast address that it does not own. The mechanism could be extended to anycast and multicast addresses if the values of the ROVR they use are known in advance, but how this is done is not in scope for this specification. One way would be to authorize in advance the ROVR of the valid users. A less preferred way could be to synchronize the ROVR and TID values across the valid registering nodes as a preshared key material.
セクション 9 では、AP-ND [RFC8928] を利用して、不正なノードが所有していないユニキャスト アドレスを登録するのを防ぎます。使用する ROVR の値が事前にわかっている場合、このメカニズムはエニーキャスト アドレスとマルチキャスト アドレスに拡張できますが、これがどのように行われるかはこの仕様の範囲外です。1 つの方法は、有効なユーザーの ROVR を事前に承認することです。あまり好ましくない方法は、有効な登録ノード全体で ROVR 値と TID 値を事前共有キー マテリアルとして同期することです。
In the latter case, it could be possible to update the keys associated to a prefix in all the 6LNs, but the flow is not clearly documented and may not complete in due time for all nodes in LLN use cases. It may be simpler to install an all-new address with new keys over a period of time and switch the traffic to that address when the migration is complete.
後者の場合、すべての 6LN のプレフィックスに関連付けられたキーを更新できる可能性がありますが、フローは明確に文書化されておらず、LLN ユースケースのすべてのノードで期限内に完了しない可能性があります。新しいキーを使用してまったく新しいアドレスを一定期間インストールし、移行が完了したらトラフィックをそのアドレスに切り替える方が簡単な場合があります。
Devices may coexist while providing different support (i.e., only [RFC8505], both [RFC8505] and [RFC9685], or those two as well as this specification). The following cases may occur:
デバイスは、異なるサポート (つまり、[RFC8505] のみ、[RFC8505] と [RFC9685] の両方、またはそれら 2 つとこの仕様) を提供しながら共存できます。次のようなケースが発生する可能性があります。
* A legacy 6LN will not register prefixes, and the service will be the same when the network is upgraded.
* 従来の 6LN はプレフィックスを登録しないため、ネットワークがアップグレードされてもサービスは同じになります。
* A legacy 6LR will not set the F flag in the 6CIO and an upgraded 6LN will not register prefixes with that router, though it may with other 6LRs that do support this specification.
* 従来の 6LR は 6CIO に F フラグを設定せず、アップグレードされた 6LN はそのルーターにプレフィックスを登録しませんが、この仕様をサポートする他の 6LR ではプレフィックスを登録する可能性があります。
* Upon an EDAR message, a legacy 6LBR may not realize that the address being registered comes with a whole prefix, and return that it is duplicate in the EDAC status. The 6LR MUST ignore a duplicate status in the EDAR for prefixes.
* EDAR メッセージを受信すると、レガシー 6LBR は、登録されているアドレスにプレフィックス全体が付いていることを認識せず、EDAC ステータスで重複していることを返す場合があります。6LR は、EDAR 内のプレフィックスの重複ステータスを無視しなければなりません (MUST)。
This specification also updates [RFC6550] and [RFC9010] in the case of a route-over multilink subnet based on the RPL routing protocol, to add multicast ingress replication in Non-Storing Mode and anycast support in both Storing and Non-Storing modes. A 6LR that implements the RPL extensions specified therein MUST also implement [RFC9010].
また、この仕様は、RPL ルーティング プロトコルに基づくルートオーバー マルチリンク サブネットの場合に [RFC6550] と [RFC9010] を更新し、非ストレージ モードでのマルチキャスト入力レプリケーションと、ストレージ モードと非ストレージ モードの両方でのエニーキャスト サポートを追加します。そこで指定された RPL 拡張を実装する 6LR は、[RFC9010] も実装しなければなりません (MUST)。
Figure 5 illustrates the classical situation of an LLN as a single IPv6 subnet, with a 6LoWPAN Border Router (6LBR) that acts as Root for RPL operations and as Address Registrar for 6LoWPAN ND.
図 5 は、RPL 操作のルートおよび 6LoWPAN ND のアドレス レジストラとして機能する 6LoWPAN ボーダー ルーター (6LBR) を備えた単一の IPv6 サブネットとしての LLN の古典的な状況を示しています。
.- -- .
.-( ).
( Internet )
(___.________.___)
|
---+-------+--
|
+--------+
| 6LBR |
| (Root) |
+--------+
o o o o
o o o
o o o o o o
o o o LLN o +-------+
o o o | 6LR | RPL Router
o o o o +-------+
o o o o +-------+ RPL
o | 6LN | leaf
+-------+ L
o : LLN node
Figure 5: RPL-Based Route-Over LLN
図 5: RPL ベースのルートオーバー LLN
A RPL leaf L acting as a 6LN registers its addresses and prefixes to a RPL router acting as a 6LR, using a L2 unicast NS message with an EARO as specified in [RFC8505] and [RFC9685]. Note that a RPL leaf acting as 6LN may still be a border router for another routing protocol, an access router for an IP link, or a virtual Router serving virtual machines or applications within the same physical node. Note also that a RPL-aware Leaf would preferably leverage RPL directly to inject routes, to fully leverage the routing protocol. The registration state is periodically renewed by the Registering Node (the 6LN), before the lifetime indicated in the EARO expires (at the 6LR). As for unicast IPv6 addresses, the 6LR uses an Extended Duplicate Address Request/Confirmation (EDAR/EDAC) exchange with the 6LBR to notify the 6LBR of the presence of the listeners. With this specification, a router that owns a prefix or provides reachability to an external prefix but is not a RPL router can also register those prefixes with the R flag set, to enable reachability to the prefix within the RPL domain.
6LN として機能する RPL リーフ L は、[RFC8505] および [RFC9685] で規定されている EARO を持つ L2 ユニキャスト NS メッセージを使用して、6LR として機能する RPL ルーターにそのアドレスとプレフィックスを登録します。6LN として機能する RPL リーフは、別のルーティング プロトコルのボーダー ルーター、IP リンクのアクセス ルーター、または同じ物理ノード内の仮想マシンまたはアプリケーションにサービスを提供する仮想ルーターである可能性があることに注意してください。また、RPL 対応リーフは、ルーティング プロトコルを最大限に活用するために、RPL を直接利用してルートを挿入することが望ましいことにも注意してください。登録状態は、EARO で示された有効期限が切れる前に、登録ノード (6LN) によって定期的に更新されます (6LR で)。ユニキャスト IPv6 アドレスの場合、6LR は 6LBR との拡張重複アドレス要求/確認 (EDAR/EDAC) 交換を使用して、6LBR にリスナーの存在を通知します。この仕様では、プレフィックスを所有しているルーター、または外部プレフィックスへの到達可能性を提供しているが RPL ルーターではないルーターも、R フラグを設定してそれらのプレフィックスを登録して、RPL ドメイン内のプレフィックスへの到達可能性を有効にすることができます。
A shared link is a situation where more than one prefix is deployed over an L2 link (say, a switched Ethernet fabric or a Wi-Fi Extended Service Set (ESS) federating multiple Access Points (APs)), and not necessarily all nodes are aware of all prefixes. Figure 6 depicts such a situation, with two routers 6LR1 and 6LR2 that own respective prefixes P1:: and P2:: and expose those in their RA messages over the same link. Note that the shared link maybe operated with any combination of NDP and SND as discussed in Section 7 of [IPv6-over-NBMA].
共有リンクとは、L2 リンク (たとえば、複数のアクセス ポイント (AP) を統合するスイッチド イーサネット ファブリックまたは Wi-Fi 拡張サービス セット (ESS)) 上に複数のプレフィックスが展開されている状況であり、必ずしもすべてのノードがすべてのプレフィックスを認識しているわけではありません。図 6 は、2 つのルーター 6LR1 と 6LR2 がそれぞれのプレフィックス P1:: と P2:: を所有し、同じリンク上の RA メッセージでそれらを公開している状況を示しています。[IPv6-over-NBMA] のセクション 7 で説明されているように、共有リンクは NDP と SND の任意の組み合わせで動作する可能性があることに注意してください。
.- -- .
.-( ).
( Internet )
(___.________.___)
|
+----+--+ +-------+
| P1::a | | P2::b |
| 6LR1 | | 6LR2 |
+---+---+ +---+---+
| |
----+--+------+---------+-+-------+---------+----
| | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+
|P1::c| |P2::d| |P2::e| |P1::f| |P1::g|
+-----+ +-----+ +-----+ +-----+ +-----+
Figure 6: Shared Link
図 6: 共有リンク
Say that 6LR1 is the router providing access to the outside, and 6LR2 is aware of 6LR1 as its default gateway. With this specification, 6LR2 registers P2:: to 6LR1, and 6LR1 installs a route to P2:: via 6LR2. This way, addresses that derive from P2:: can still be reached via 6LR1 and then 6LR2. 6LR2 may then leverage ICMP Redirect messages [RFC4861] to shorten the path between 6LR1 and the nodes that own those addresses.
6LR1 が外部へのアクセスを提供するルーターであり、6LR2 が 6LR1 をデフォルト ゲートウェイとして認識しているとします。この仕様では、6LR2 が 6LR1 に P2:: を登録し、6LR1 が 6LR2 経由で P2:: へのルートをインストールします。このようにすると、P2:: から派生したアドレスには、6LR1 を介して、さらに 6LR2 を介して到達することができます。その後、6LR2 は ICMP リダイレクト メッセージ [RFC4861] を利用して、6LR1 とそれらのアドレスを所有するノード間のパスを短縮する可能性があります。
If P2 were delegated by 6LR1, e.g., using DHCPv6 [RFC9915], then the expectation is that 6LR1 aggregates P1:: and P2:: in its advertisements to the outside, and there is no need to set the R flag. However, unless 6LR2 knows about such a situation, e.g., through configuration, 6LR2 SHOULD set the R flag requesting 6LR1 to advertise P2:: so as to obtain reachability.
たとえば、DHCPv6 [RFC9915] を使用して、P2 が 6LR1 によって委任された場合、6LR1 が外部へのアドバタイズメントで P1:: と P2:: を集約することが期待され、R フラグを設定する必要はありません。しかし、6LR2がそのような状況を、例えば設定を通じて知らない限り、6LR2は、到達可能性を得るために、6LR1にP2::をアドバタイズするよう要求するRフラグを設定すべきである(SHOULD)。
A hub link is a situation where stub links are deployed around a backbone and interconnected by routers. Figure 7 depicts such a situation, with one router 6LR1 serving the hub link and at least one router like 6LR2 and 6LR3 providing connectivity from the stub links to the hub link. In this example, say that there is one prefix on each link -- P1:: on the hub link, and P2:: and P3:: on the stub links.
ハブ リンクは、スタブ リンクがバックボーンの周囲に配置され、ルーターによって相互接続されている状況です。図 7 はそのような状況を示しており、1 つのルータ 6LR1 がハブ リンクにサービスを提供し、6LR2 や 6LR3 のような少なくとも 1 つのルータがスタブ リンクからハブ リンクへの接続を提供しています。この例では、各リンクに 1 つのプレフィックスがあるとします。ハブ リンクには P1::、スタブ リンクには P2:: と P3:: があります。
+-----+ +-----+ +-----+ +-----+
|P2::s| |P2::d| |P2::e| |P2::f|
+--+--+ +--+--+ +--+--+ +--+--+
| | | |
----+----+----+---------+--STUB-LINK--+-----
|
+---+---+ +-------+
| P2::r | | | .- --..
| 6LR2 | | 6LR1 +---- .-( ).
| P1::b | | P1::a | ( Internet )
+---+---+ +---+---+ (___._______.___)
| | |
-------+-+---------+--HUB-LINK--+-----+-- |
| | | |
+---+---+ +--+--+ +---+---+ |
| P1::c | |P1::n| | P1::q | |
| 6LR3 | +-----+ | 6LR4 +----+
| P3::m | | P3::a |
+---+---+ +---+---+
| |
----+--+------+---------+--STUB-LINK--+-+-----
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
|P3::h| |P3::i| |P3::j| |P3::k|
+-----+ +-----+ +-----+ +-----+
Figure 7: Hub and Stubs
図 7: ハブとスタブ
As before, say that 6LR1 is the router providing access to the outside, and 6LR2 is aware of 6LR1 as its default gateway. With this specification, 6LR2 registers P2:: to 6LR1, and 6LR1 installs a route to P2:: via 6LR2. This way, nodes on the stub link behind 6LR2 that derive their addresses from P2:: can still be reached via 6LR1 and then 6LR2. The same goes for 6LR3 and any other routers serving stub links.
前と同様に、6LR1 が外部へのアクセスを提供するルータであり、6LR2 が 6LR1 をデフォルト ゲートウェイとして認識しているとします。この仕様では、6LR2 が 6LR1 に P2:: を登録し、6LR1 が 6LR2 経由で P2:: へのルートをインストールします。このようにすると、P2:: からアドレスを取得する 6LR2 の背後にあるスタブ リンク上のノードには、6LR1 を経由して、次に 6LR2 を経由してアクセスできます。6LR3 およびスタブ リンクを提供する他のルータにも同じことが当てはまります。
If P2 were delegated by 6LR1, then the expectation is that 6LR1 aggregates P1:: and P2:: in its advertisements to the outside, and there is no need to set the R flag. However, unless 6LR2 knows about such a situation, e.g., through configuration, 6LR2 SHOULD set the R flag requesting 6LR1 to advertise P2:: so as to obtain reachability.
P2 が 6LR1 によって委任されている場合、6LR1 は外部へのアドバタイズメントで P1:: と P2:: を集約することが期待されるため、R フラグを設定する必要はありません。しかし、6LR2がそのような状況を、例えば設定を通じて知らない限り、6LR2は、到達可能性を得るために、6LR1にP2::をアドバタイズするよう要求するRフラグを設定すべきである(SHOULD)。
In this example, routers 6LR3 and 6LR4 both connect to the same stub link where subnet P3 is installed. They may both register P3 to 6LR1, and 6LR1 will apply its own load-balancing logic to use either of the routers.
この例では、ルーター 6LR3 と 6LR4 は両方とも、サブネット P3 がインストールされている同じスタブ リンクに接続します。これらは両方とも P3 を 6LR1 に登録することができ、6LR1 は独自の負荷分散ロジックを適用していずれかのルーターを使用します。
IANA has made changes under the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" [IANA.ICMP] and the "Routing Protocol for Low Power and Lossy Networks (RPL)" [IANA.RPL] registry groups, as follows.
IANA は、「Internet Control Message Protocol version 6 (ICMPv6) Parameters」[IANA.ICMP] および「Routing Protocol for Low Power and Lossy Networks (RPL)」[IANA.RPL] レジストリ グループを次のように変更しました。
This specification updates the P-Field introduced in [RFC9685] to assign the value of 3, which is the only remaining unassigned value for the 2-bit field. To that effect, IANA has updated the "P-Field Values" registry in the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry group as indicated in Table 2:
この仕様は、[RFC9685] で導入された P フィールドを更新して、2 ビット フィールドに唯一残っている未割り当ての値である 3 の値を割り当てます。そのため、IANA は、表 2 に示すように、「Internet Control Message Protocol version 6 (ICMPv6) Parameters」レジストリ グループの「P-Field Values」レジストリを更新しました。
+=======+===================================+===========+
| Value | Meaning | Reference |
+=======+===================================+===========+
| 3 | Registration for a Unicast Prefix | RFC 9926 |
+-------+-----------------------------------+-----------+
Table 2: New P-Field Value
表 2: 新しい P フィールド値
IANA has made an addition to the "6LoWPAN Capability Bits" [IANA.ICMP.6CIO] registry in the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry group as indicated in Table 3:
IANA は、表 3 に示すように、「Internet Control Message Protocol version 6 (ICMPv6) Parameters」レジストリ グループの「6LoWPAN Capability Bits」[IANA.ICMP.6CIO] レジストリに追加を行いました。
IANA has fixed the description of bit 9 (the "A" flag defined in [RFC8928]). It is not called "1" but "A".
IANA はビット 9 ([RFC8928] で定義されている「A」フラグ) の説明を修正しました。「1」ではなく「A」と呼びます。
+=====+=============================================+===========+
| Bit | Description | Reference |
+=====+=============================================+===========+
| 9 | AP-ND Enabled (A bit) | [RFC8928] |
+-----+---------------------------------------------+-----------+
| 16 | Registration for prefixes supported (F bit) | RFC 9926 |
+-----+---------------------------------------------+-----------+
Table 3: New 6LoWPAN Capability Bit
表 3: 新しい 6LoWPAN 機能ビット
[IANA.ICMP]
IANA, "Internet Control Message Protocol version 6
(ICMPv6) Parameters",
<https://www.iana.org/assignments/icmpv6-parameters>.
[IANA.ICMP.6CIO]
IANA, "6LoWPAN Capability Bits",
<https://www.iana.org/assignments/icmpv6-parameters>.
[IANA.RPL] IANA, "Routing Protocol for Low Power and Lossy Networks
(RPL)", <https://www.iana.org/assignments/rpl>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>.
[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>.
[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November
2014, <https://www.rfc-editor.org/info/rfc7400>.
[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>.
[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>.
[RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL
(Routing Protocol for Low-Power and Lossy Networks)
Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021,
<https://www.rfc-editor.org/info/rfc9010>.
[RFC9685] Thubert, P., Ed., "Listener Subscription for IPv6 Neighbor
Discovery Multicast and Anycast Addresses", RFC 9685,
DOI 10.17487/RFC9685, November 2024,
<https://www.rfc-editor.org/info/rfc9685>.
[BCP38] Best Current Practice 38,
<https://www.rfc-editor.org/info/bcp38>.
At the time of writing, this BCP comprises the following:
Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[IEEE80211]
IEEE, "IEEE Standard for Information Technology --
Telecommunications and Information Exchange between
Systems - Local and Metropolitan Area Networks -- Specific
Requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", IEEE
Std 802.11-2022, DOI 10.1109/IEEESTD.2021.9363693,
<https://ieeexplore.ieee.org/document/9363693>.
[IEEE802151]
IEEE, "IEEE Standard for Telecommunications and
Information Exchange Between Systems - LAN/MAN - Specific
Requirements - Part 15: Wireless Medium Access Control
(MAC) and Physical Layer (PHY) Specifications for Wireless
Personal Area Networks (WPANs)", IEEE Std 802.15.1-2002,
DOI 10.1109/IEEESTD.2002.93621,
<https://ieeexplore.ieee.org/document/1016473>.
[IEEE802154]
IEEE, "IEEE Standard for Information technology -- Local
and metropolitan area networks -- Specific requirements --
Part 15.4: Wireless Medium Access Control (MAC) and
Physical Layer (PHY) Specifications for Low Rate Wireless
Personal Area Networks (WPANs)", IEEE Std 802.15.4-2006,
DOI 10.1109/IEEESTD.2006.232110,
<https://ieeexplore.ieee.org/document/1700009>.
[IPv6-over-NBMA]
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>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, DOI 10.17487/RFC4919, August 2007,
<https://www.rfc-editor.org/info/rfc4919>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>.
[RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time-
Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
RFC 9030, DOI 10.17487/RFC9030, May 2021,
<https://www.rfc-editor.org/info/rfc9030>.
[RFC9915] Mrugalski, T., Volz, B., Richardson, M., Jiang, S., and T.
Winters, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", STD 102, RFC 9915, DOI 10.17487/RFC9915,
January 2026, <https://www.rfc-editor.org/info/rfc9915>.
[WI-SUN] "Wi-SUN Alliance", <https://wi-sun.org/>.
Many thanks to Dave Thaler and Dan Romascanu for their early reviews, Adnan Rashid for all his contributions, and Éric Vyncke for his in-depth AD review. Many thanks as well to the reviewers of the IETF Last Call and IESG rounds: Dan Romascanu, Shuping Peng, Mohamed Boucadair, Paul Wouters, Ketan Talaulikar, Gunter Van de Velde, Mike Bishop, and Roman Danyliw.
初期のレビューに対して Dave Thaler と Dan Romascanu、すべての貢献に対して Adnan Rashid、そして詳細な AD レビューに対して Éric Vyncke に多大な感謝を申し上げます。IETF Last Call および IESG ラウンドの審査員である Dan Romascanu、Shuping Peng、Mohamed Boucadair、Paul Wouters、Ketan Talaulikar、Gunter Van de Velde、Mike Bishop、Roman Danyliw にも多大な感謝を申し上げます。
Pascal Thubert (editor)
06330 Roquefort-les-Pins
France
Email: pascal.thubert@gmail.com