| rfc9926v2.txt | rfc9926.txt | |||
|---|---|---|---|---|
| Internet Engineering Task Force (IETF) P. Thubert, Ed. | Internet Engineering Task Force (IETF) P. Thubert, Ed. | |||
| Request for Comments: 9926 January 2026 | Request for Comments: 9926 January 2026 | |||
| Updates: 4861, 6550, 8505, 8928, 9010 | Updates: 4861, 6550, 8505, 8928, 9010 | |||
| Category: Standards Track | Category: Standards Track | |||
| ISSN: 2070-1721 | ISSN: 2070-1721 | |||
| IPv6 Neighbor Discovery Prefix Registration | Prefix Registration for IPv6 Neighbor Discovery | |||
| Abstract | Abstract | |||
| This document updates IPv6 Neighbor Discovery (RFC 4861) and IPv6 | This document updates IPv6 Neighbor Discovery (RFC 4861) and IPv6 | |||
| Subnet Neighbor Discovery (RFC 8505, RFC 8928) to enable a node that | 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 | owns or is directly connected to a prefix to register that prefix to | |||
| neighbor routers. The registration indicates that the registered | neighbor routers. The registration indicates that the registered | |||
| prefix can be reached via the advertising node without a loop. The | prefix can be reached via the advertising node without a loop. The | |||
| unicast prefix registration allows the node to request one or more | unicast prefix registration allows the node to request one or more | |||
| neighbor routers to redistribute the prefix in another routing domain | neighbor routers to redistribute the prefix in another routing domain | |||
| skipping to change at line 233 ¶ | skipping to change at line 233 ¶ | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
| BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 2.2. Inherited Terms and Concepts | 2.2. Inherited Terms and Concepts | |||
| This document uses terms and concepts that are discussed in: | This document uses terms and concepts that are discussed in: | |||
| * "TLS User Mapping Extension" [RFC4861] and | * "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861] and | |||
| * "IPv6 Stateless Address Autoconfiguration" [RFC4862] for the | * "IPv6 Stateless Address Autoconfiguration" [RFC4862] for the | |||
| Neighbor Solicitation operation, | Neighbor Solicitation operation, | |||
| * "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless | * "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless | |||
| Personal Area Networks (6LoWPANs)" [RFC6775], as well as | Personal Area Networks (6LoWPANs)" [RFC6775], as well as | |||
| * "Registration Extensions for IPv6 over Low-Power Wireless Personal | * "Registration Extensions for IPv6 over Low-Power Wireless Personal | |||
| Area Network (6LoWPAN) Neighbor Discovery" [RFC8505], and | Area Network (6LoWPAN) Neighbor Discovery" [RFC8505], and | |||
| skipping to change at line 268 ¶ | skipping to change at line 268 ¶ | |||
| DAO: Destination Advertisement Object [RFC6550] | DAO: Destination Advertisement Object [RFC6550] | |||
| DODAG: Destination-Oriented Directed Acyclic Graph | DODAG: Destination-Oriented Directed Acyclic Graph | |||
| EARO: Extended Address Registration Option [RFC8505] | EARO: Extended Address Registration Option [RFC8505] | |||
| EDAC: Extended Duplicate Address Confirmation [RFC8505] | EDAC: Extended Duplicate Address Confirmation [RFC8505] | |||
| EDAR: Extended Duplicate Address Request [RFC8505] | EDAR: Extended Duplicate Address Request [RFC8505] | |||
| ESS: Extended Service Set [IEEE80211] | ESS: Extended Service Set [IEEE80211] | |||
| IPAM: IP Address Management | IPAM: IP Address Management | |||
| LLN: Low-Power and Lossy Network | LLN: Low-Power and Lossy Network | |||
| LLA: Link-Layer Address | LLA: Link-Layer Address | |||
| LoWPAN: Low-Power Wireless Personal Area Network | LoWPAN: Low-Power Wireless Personal Area Network | |||
| LR-WPAN: Low-Rate Personal Area Network [IEEE802154] | LR-WPAN: Low-Rate Wireless Personal Area Network [IEEE802154] | |||
| MAC: Medium Access Control | MAC: Medium Access Control | |||
| NA: Neighbor Advertisement (message) [RFC4861] | NA: Neighbor Advertisement (message) [RFC4861] | |||
| NBMA: Non-Broadcast Multi-Access (full mesh) | NBMA: Non-Broadcast Multi-Access (full mesh) | |||
| NCE: Neighbor Cache Entry [RFC4861] | NCE: Neighbor Cache Entry [RFC4861] | |||
| ND: Neighbor Discovery (protocol) | ND: Neighbor Discovery (protocol) | |||
| NDP: Neighbor Discovery Protocol | NDP: Neighbor Discovery Protocol | |||
| NS: Neighbor Solicitation (message) [RFC4861] | NS: Neighbor Solicitation (message) [RFC4861] | |||
| ROVR: Registration Ownership Verifier (pronounced "rover") | ROVR: Registration Ownership Verifier (pronounced "rover") | |||
| [RFC8505] | [RFC8505] | |||
| RPL: IPv6 Routing Protocol for LLNs (pronounced "ripple") | RPL: IPv6 Routing Protocol for LLNs (pronounced "ripple") | |||
| skipping to change at line 291 ¶ | skipping to change at line 291 ¶ | |||
| RS: Router Solicitation (message) [RFC4861] | RS: Router Solicitation (message) [RFC4861] | |||
| RTO: RPL Target Option [RFC6550] | RTO: RPL Target Option [RFC6550] | |||
| SLLAO: Source Link-Layer Address Option [RFC4861] | SLLAO: Source Link-Layer Address Option [RFC4861] | |||
| SND: Subnet Neighbor Discovery (protocol) | SND: Subnet Neighbor Discovery (protocol) | |||
| TID: Transaction ID [RFC8505] | TID: Transaction ID [RFC8505] | |||
| TIO: Transit Information Option [RFC6550] | TIO: Transit Information Option [RFC6550] | |||
| TLLAO: Target Link-Layer Address Option [RFC4861] | TLLAO: Target Link-Layer Address Option [RFC4861] | |||
| 2.4. New Terms | 2.4. New Terms | |||
| This document introduces the following terms: | This document introduces the following term: | |||
| Origin: The node that issued the prefix advertisement, either in the | Origin: The node that issued the prefix advertisement, either in the | |||
| form of a NS(EARO) or as a DAO(TIO, RTO) | form of a NS(EARO) or as a DAO(TIO, RTO) | |||
| Merge: The action of receiving multiple anycast or multicast | ||||
| advertisements, either (1) internally from self, (2) in the | ||||
| form of a NS(EARO), or (3) as a DAO(TIO, RTO), and generating | ||||
| a single DAO(TIO, RTO). The 6RPL router maintains a state per | ||||
| origin for each advertised address, and merges the | ||||
| advertisements for all subscriptions for the same address in a | ||||
| single advertisement. A RPL router that merges then becomes | ||||
| the origin of the merged advertisement and uses its own values | ||||
| for the Path Sequence and ROVR fields. | ||||
| 3. Overview | 3. Overview | |||
| This specification inherits from [RFC6550], [RFC8505], and [RFC9010] | This specification inherits from [RFC6550], [RFC8505], and [RFC9010] | |||
| to register prefixes as opposed to addresses. | to register prefixes as opposed to addresses. | |||
| An SND deployment consists of: | 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: | ||||
| * one or more 6LBRs that act as RPL Root, | * one or more 6LBRs that act as RPL Root, | |||
| * intermediate routers down the RPL graph that propagate routing | * intermediate routers down the RPL graph that propagate routing | |||
| information on addresses and prefixes towards the Root, | information on addresses and prefixes towards the Root, | |||
| * 6LRs that are RPL-aware 6LNs and can leverage RPL directly to | * 6LRs that are RPL-aware 6LNs and can leverage RPL directly to | |||
| expose their addresses and prefixes, and | expose their addresses and prefixes, and | |||
| * 6LNs that are the RPL-unaware destinations and need SND to obtain | * 6LNs that are the RPL-unaware destinations and need SND to obtain | |||
| skipping to change at line 457 ¶ | skipping to change at line 450 ¶ | |||
| [RFC6550] uses the Path Lifetime in the TIO to indicate the remaining | [RFC6550] uses the Path Lifetime in the TIO to indicate the remaining | |||
| time for which the advertisement is valid for unicast route | time for which the advertisement is valid for unicast route | |||
| determination, and a Path Lifetime value of 0 invalidates that route. | determination, and a Path Lifetime value of 0 invalidates that route. | |||
| [RFC9010] maps the Address Registration lifetime in the EARO and the | [RFC9010] maps the Address Registration lifetime in the EARO and the | |||
| Path Lifetime in the TIO so they are comparable when both forms of | Path Lifetime in the TIO so they are comparable when both forms of | |||
| advertisements are received. | advertisements are received. | |||
| The RPL router that merges multiple advertisements for the same | The RPL router that merges multiple advertisements for the same | |||
| prefix uses and advertises the longest remaining lifetime across all | prefix uses and advertises the longest remaining lifetime across all | |||
| the origins of the advertisements for that prefix. When the lifetime | the origins of the advertisements for that prefix. When the lifetime | |||
| expires, the router sends a no-path DAO (i.e., the lifetime is 0) | expires, the router sends a no-path DAO message (i.e., the lifetime | |||
| using the same value for the ROVR value as for the previous | is 0) using the same value for the ROVR value as for the previous | |||
| advertisements. This value refers to either the router itself or the | advertisements. This value refers to either the single descendant | |||
| single descendant that advertised the Target. | that advertised the Target if there is only one or the router itself | |||
| if there is more than one. | ||||
| Note that the Registration Lifetime, TID, and ROVR fields are also | Note that the Registration Lifetime, TID, and ROVR fields are also | |||
| placed in the EDAR message, so the state created by EDAR is 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 | 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 | simplicity, the text below mentions only NS(EARO) but it also applies | |||
| to EDAR. | to EDAR. | |||
| 7. Updating RFC 8505 | 7. Updating RFC 8505 | |||
| This specification updates the EARO and EDAR messages to enable the | This specification updates the EARO and EDAR messages to enable the | |||
| End of changes. 7 change blocks. | ||||
| 18 lines changed or deleted | 12 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. | ||||