idnits 2.17.1 draft-ietf-6lo-multicast-registration-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC9010, but the abstract doesn't seem to directly say this. It does mention RFC9010 though, so this could be OK. -- The draft header indicates that this document updates RFC6553, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (22 June 2022) is 674 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-thubert-bess-secure-evpn-mac-signaling-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Updates: 6550, 6553, 8505, 9010 (if approved) 22 June 2022 5 Intended status: Standards Track 6 Expires: 24 December 2022 8 IPv6 Neighbor Discovery Multicast Address Listener Registration 9 draft-ietf-6lo-multicast-registration-07 11 Abstract 13 This document updates RFC 8505 to enable a listener to register an 14 IPv6 anycast or and subscribe to an IPv6 multicast address; the draft 15 updates RFC 6550 (RPL) to add a new Non-Storing Multicast Mode and a 16 new support for anycast addresses in Storing and Non-Storing Modes. 17 This document extends RFC 9010 to enable the 6LR to inject the 18 anycast and multicast addresses in RPL. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 24 December 2022. 37 Copyright Notice 39 Copyright (c) 2022 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Revised BSD License text as 48 described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Revised BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 56 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. Extending RFC 7400 . . . . . . . . . . . . . . . . . . . . . 9 60 5. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 10 61 5.1. Updating MOP 3 . . . . . . . . . . . . . . . . . . . . . 10 62 5.2. New Non-Storing Multicast MOP . . . . . . . . . . . . . . 10 63 5.3. RPL Anycast Operation . . . . . . . . . . . . . . . . . . 11 64 5.4. New RPL Target Option Flags . . . . . . . . . . . . . . . 13 65 6. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 13 66 6.1. New EARO flag . . . . . . . . . . . . . . . . . . . . . . 13 67 6.2. New EDAR Message Flag field . . . . . . . . . . . . . . . 14 68 6.3. Registering Extensions . . . . . . . . . . . . . . . . . 15 69 7. Updating RFC 9010 . . . . . . . . . . . . . . . . . . . . . . 18 70 8. Leveraging RFC 8928 . . . . . . . . . . . . . . . . . . . . . 18 71 9. Node Uptime Option . . . . . . . . . . . . . . . . . . . . . 19 72 10. Deployment considerations . . . . . . . . . . . . . . . . . . 21 73 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 74 12. Backward Compatibility . . . . . . . . . . . . . . . . . . . 23 75 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 76 13.1. New EDAR Message Flags Subregistry . . . . . . . . . . . 24 77 13.2. New EARO flags . . . . . . . . . . . . . . . . . . . . . 24 78 13.3. New RTO flags . . . . . . . . . . . . . . . . . . . . . 25 79 13.4. New RPL Mode of Operation . . . . . . . . . . . . . . . 25 80 13.5. New 6LoWPAN Capability Bits . . . . . . . . . . . . . . 26 81 13.6. New Address Registration Option Status Values . . . . . 26 82 13.7. New IPv6 Neighbor Discovery Option . . . . . . . . . . . 26 83 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 84 15. Normative References . . . . . . . . . . . . . . . . . . . . 27 85 16. Informative References . . . . . . . . . . . . . . . . . . . 29 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 88 1. Introduction 90 The design of Low Power and Lossy Networks (LLNs) is generally 91 focused on saving energy, which is the most constrained resource of 92 all. Other design constraints, such as a limited memory capacity, 93 duty cycling of the LLN devices and low-power lossy transmissions, 94 derive from that primary concern. The radio (both transmitting or 95 simply listening) is a major energy drain and the LLN protocols must 96 be adapted to allow the nodes to remain sleeping with the radio 97 turned off at most times. 99 The "Routing Protocol for Low Power and Lossy Networks" [RFC6550] 100 (RPL) provides IPv6 [RFC8200] routing services within such 101 constraints. To save signaling and routing state in constrained 102 networks, the RPL routing is only performed along a Destination- 103 Oriented Directed Acyclic Graph (DODAG) that is optimized to reach a 104 Root node, as opposed to along the shortest path between 2 peers, 105 whatever that would mean in each LLN. 107 This trades the quality of peer-to-peer (P2P) paths for a vastly 108 reduced amount of control traffic and routing state that would be 109 required to operate an any-to-any shortest path protocol. 110 Additionally, broken routes may be fixed lazily and on-demand, based 111 on dataplane inconsistency discovery, which avoids wasting energy in 112 the proactive repair of unused paths. 114 Section 12 of [RFC6550] details the "Storing Mode of Operation with 115 multicast support" with source-independent multicast routing in RPL. 117 The classical "IPv6 Neighbor Discovery (IPv6 ND) Protocol" [RFC4861] 118 [RFC4862] was defined for serial links and shared transit media such 119 as Ethernet at a time when broadcast was cheap on those media while 120 memory for neighbor cache was expensive. It was thus designed as a 121 reactive protocol that relies on caching and multicast operations for 122 the Address Discovery (aka Lookup) and Duplicate Address Detection 123 (DAD) of IPv6 unicast addresses. Those multicast operations 124 typically impact every node on-link when at most one is really 125 targeted, which is a waste of energy, and imply that all nodes are 126 awake to hear the request, which is inconsistent with power saving 127 (sleeping) modes. 129 The original 6LoWPAN ND, "Neighbor Discovery Optimizations for 130 6LoWPAN networks" [RFC6775], was introduced to avoid the excessive 131 use of multicast messages and enable IPv6 ND for operations over 132 energy-constrained nodes. [RFC6775] changes the classical IPv6 ND 133 model to proactively establish the Neighbor Cache Entry (NCE) 134 associated to the unicast address of a 6LoWPAN Node (6LN) in the a 135 6LoWPAN Router(s) (6LR) that serves it. To that effect, [RFC6775] 136 defines a new Address Registration Option (ARO) that is placed in 137 unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA) 138 messages between the 6LN and the 6LR. 140 "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] 141 updates [RFC6775] into a generic Address Registration mechanism that 142 can be used to access services such as routing and ND proxy and 143 introduces the Extended Address Registration Option (EARO) for that 144 purpose. This provides a routing-agnostic interface for a host to 145 request that the router injects a unicast IPv6 address in the local 146 routing protocol and provide return reachability for that address. 148 "Routing for RPL Leaves" [RFC9010] provides the router counterpart of 149 the mechanism for a host that implements [RFC8505] to inject its 150 unicast Unique Local Addresses (ULAs) and Global Unicast Addresses 151 (GUAs) in RPL. But though RPL also provides multicast routing, 152 6LoWPAN ND supports only the registration of unicast addresses and 153 there is no equivalent of [RFC9010] to specify the 6LR behavior upon 154 the registration of one or more multicast address. 156 The "Multicast Listener Discovery Version 2 (MLDv2) for IPv6" 157 [RFC3810] enables the router to learn which node listens to which 158 multicast address, but as the classical IPv6 ND protocol, MLD relies 159 on multicasting Queries to all nodes, which is unfit for low power 160 operations. As for IPv6 ND, it makes sense to let the 6LNs control 161 when and how they maintain the state associated to their multicast 162 addresses in the 6LR, e.g., during their own wake time. In the case 163 of a constrained node that already implements [RFC8505] for unicast 164 reachability, it makes sense to extend to that support to register 165 the multicast addresses they listen to. 167 This specification extends [RFC8505] and [RFC9010] to add the 168 capability for the 6LN to register anycast and multicast addresses 169 and for the 6LR to inject them in RPL when appropriate. 171 2. Terminology 173 2.1. Requirements Language 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 177 "OPTIONAL" in this document are to be interpreted as described in BCP 178 14 [RFC2119] [RFC8174] when, and only when, they appear in all 179 capitals, as shown here. 181 2.2. References 183 This document uses terms and concepts that are discussed in: 185 * "Neighbor Discovery for IP version 6" [RFC4861] and "IPv6 186 Stateless address Autoconfiguration" [RFC4862], 188 * Neighbor Discovery Optimization for Low-Power and Lossy Networks 189 [RFC6775], as well as 191 * "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] 192 and 194 * "Using RPI Option Type, Routing Header for Source Routes, and 195 IPv6-in-IPv6 Encapsulation in the RPL Data Plane" [RFC9008]. 197 2.3. Glossary 199 This document uses the following acronyms: 201 6BBR 6LoWPAN Backbone Router 202 6BBR 6LoWPAN Border Router 203 6LN 6LoWPAN Node 204 6LR 6LoWPAN Router 205 6CIO Capability Indication Option 206 AMC Address Mapping Confirmation 207 AMR Address Mapping Request 208 ARO Address Registration Option 209 DAC Duplicate Address Confirmation 210 DAD Duplicate Address Detection 211 DAR Duplicate Address Request 212 EARO Extended Address Registration Option 213 EDAC Extended Duplicate Address Confirmation 214 EDAR Extended Duplicate Address Request 215 DODAG Destination-Oriented Directed Acyclic Graph 216 IR Ingress Replication 217 LLN Low-Power and Lossy Network 218 NA Neighbor Advertisement 219 NCE Neighbor Cache Entry 220 ND Neighbor Discovery 221 NS Neighbor Solicitation 222 ROVR Registration Ownership Verifier 223 RTO RPL Target Option 224 RA Router Advertisement 225 RS Router Solicitation 226 TID Transaction ID 227 TIO Transit Information Option 229 3. Overview 231 This specification inherits from [RFC6550], [RFC8505], and [RFC9010] 232 to provide additional capabilities for anycast and multicast. Unless 233 specified otherwise therein, the behavior of the 6LBR that acts as 234 RPL Root, of the intermediate routers down the RPL graph, of the 6LR 235 that act as access routers and of the 6LNs that are the RPL-unaware 236 destinations, is the same as for unicast. In particular, forwarding 237 a packet happens as specified in section 11 of [RFC6550], including 238 loop avoidance and detection, though in the case of multicast 239 multiple copies might be generated. 241 [RFC8505] is a pre-requisite to this specification. A node that 242 implements this MUST also implement [RFC8505]. This specification 243 does not introduce a new option; it modifies existing options and 244 updates the associated behaviors to enable the Registration for 245 Multicast Addresses as an extension to [RFC8505]. 247 This specification also extends [RFC6550] and [RFC9010] in the case 248 of a route-over multilink subnet based on the RPL routing protocol, 249 to add multicast ingress replication in Non-Storing Mode and anycast 250 support in both Storing and Non-Storing modes. A 6LR that implements 251 the RPL extensions specified therein MUST also implement [RFC9010]. 253 Figure 1 illustrates the classical situation of an LLN as a single 254 IPv6 Subnet, with a 6LoWPAN Border Router (6LBR) that acts as Root 255 for RPL operations and maintains a registry of the active 256 registrations as an abstract data structure called an Address 257 Registrar for 6LoWPAN ND. 259 The LLN may be a hub-and-spoke access link such as (Low-Power) Wi-Fi 260 [IEEE Std 802.11] and Bluetooth (Low Energy) [IEEE Std 802.15.1], or 261 a Route-Over LLN such as the Wi-SUN and 6TiSCH meshes [Wi-SUN] that 262 leverages 6LoWPAN [RFC4919][RFC6282] and RPL [RFC6550] over [IEEE Std 263 802.15.4]. 265 | 266 ----+-------+------------ 267 | Wire side 268 +------+ 269 | 6LBR | 270 |(Root)| 271 +------+ 272 o o o Wireless side 273 o o o o o o 274 o o o o o o o 275 o o o LLN o +---+ 276 o o o o o |6LR| 277 o o o o o +---+ 278 o o o o o o z 279 o o oo o o +---+ 280 o |6LN| 281 +---+ 283 Figure 1: Wireless Mesh 285 A leaf acting as a 6LN registers its unicast and anycast addresses a 286 RPL router acting as a 6LR, using a layer-2 unicast NS message with 287 an EARO as specified in [RFC8505]. The registration state is 288 periodically renewed by the Registering Node, before the lifetime 289 indicated in the EARO expires. As for unicast IPv6 addresses, the 290 6LR uses an EDAR/EDAC exchange with the 6LBR to notify the 6LBR of 291 the presence of the listeners. 293 This specification updates the EARO with two new flags, the A flag 294 for Anycast, and the M flag for Multicast, as detailed in 295 Section 6.1. The existing R flag that requests reachability for the 296 registered address gets new behavior. With this extension the 6LNs 297 can now subscribe to the multicast addresses they listen to, using a 298 new M flag in the EARO to signal that the registration is for a 299 multicast address. Multiple 6LN may subscribe to the same multicast 300 address to the same 6LR. Note the use of the term "subscribe": using 301 the EARO registration mechanism, a node registers the unicast 302 addresses that it owns, but subscribes to the multicast addresses 303 that it listens to. 305 With this specification, the 6LNs can also register the anycast 306 addresses they accept, using a new A flag in the EARO to signal that 307 the registration is for an anycast address. As for multicast, 308 multiple 6LN may register the same anycast address to the same 6LR. 310 If the R flag is set in the registration of one or more 6LNs for the 311 same address, the 6LR injects the anycast addresses and multicast 312 addresses of a scope larger than link-scope in RPL, based on the 313 longest registration lifetime across the active registrations for the 314 address. 316 In the RPL "Storing Mode of Operation with multicast support", the 317 DAO messages for the multicast address percolate along the RPL 318 preferred parent tree and mark a subtree that becomes the multicast 319 tree for that multicast address, with 6LNs that subscribed to the 320 address as the leaves. As prescribed in section 12 of [RFC6550], the 321 6LR forwards a multicast packet as an individual unicast MAC frame to 322 each peer along the multicast tree, excepting to the node it received 323 the packet from. 325 In the new RPL "Non-Storing Mode of Operation with multicast support" 326 that is introduced here, the DAO messages announce the multicast 327 addresses as Targets though never as Transit. The multicast 328 distribution is an ingress replication whereby the Root encapsulates 329 the multicast packets to all the 6LRs that are transit for the 330 multicast address, using the same source-routing header as for 331 unicast targets attached to the respective 6LRs. 333 Broadcasting is typically unreliable in LLNs (no ack) and forces a 334 listener to remain awake, so it generally discouraged. The 335 expectation is thus that in either mode, the 6LRs deliver the 336 multicast packets as individual unicast MAC frames to each of the 337 6LNs that subscribed to the multicast address. 339 With this specification, anycast addresses can be injected in RPL in 340 both Storing and Non-Storing modes. In Storing Mode the RPL router 341 accepts DAO from multiple children for the same anycast address, but 342 only forwards a packet to one of the children. In Non-Storing Mode, 343 the Root maintains the list of all the RPL nodes that announced the 344 anycast address as Target, but forwards a given packet to only one of 345 them. 347 For backward compatibility, this specification allows to build a 348 single DODAG signaled as MOP 1, that conveys anycast, unicast and 349 multicast packets using the same source routing mechanism, more in 350 Section 10. 352 It is also possible to leverage this specification between the 6LN 353 and the 6LR for the registration of unicast, anycast and multicast 354 IPv6 addresses in networks that are not necessarily LLNs, and/or 355 where the routing protocol between the 6LR and above is not 356 necessarily RPL. In that case, the distribution of packets between 357 the 6LR and the 6LNs may effectively rely on a broadcast or multicast 358 support at the lower layer, e.g., using this specification as a 359 replacement to MLD in an Ethernet bridged domain and still using 360 either plain MAC-layer broadcast or snooping this protocol to control 361 the flooding. It may also rely on overlay services to optimize the 362 impact of Broadcast, Unknown and Multicast (BUM) over a fabric, e.g. 363 registering with [I-D.thubert-bess-secure-evpn-mac-signaling] and 364 forwarding with [I-D.ietf-bess-evpn-optimized-ir]. 366 For instance, it is possible to operate a RPL Instance in the new 367 "Non-Storing Mode of Operation with multicast support" (while 368 possibly signaling a MOP of 1) and use "Multicast Protocol for 369 Low-Power and Lossy Networks (MPL)" [RFC7731] for the multicast 370 operation. MPL floods the DODAG with the multicast messages 371 independently of the RPL DODAG topologies. Two variations are 372 possible: 374 * In one possible variation, all the 6LNs set the R flag in the EARO 375 for a multicast target, upon which the 6LRs send a unicast DAO 376 message to the Root; the Root filters out the multicast messages 377 for which there is no listener and only floods when there is. 379 * In a simpler variation, the 6LNs do not set the R flag and the 380 Root floods all the multicast packets over the whole DODAG. Using 381 configuration, it is also possible to control the behavior of the 382 6LR to ignore the R flag and either always or never send the DAO 383 message, and/or to control the Root and specify which groups it 384 should flood or not flood. 386 Note that if the configuration instructs the 6LR not to send the DAO, 387 then MPL can really by used in conjunction with RPL Storing Mode as 388 well. 390 4. Extending RFC 7400 392 This specification defines a new capability bit for use in the 6CIO 393 as defined by "6LoWPAN-GHC: Generic Header Compression for IPv6 over 394 Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC7400] and 395 extended in [RFC8505] for use in IPv6 ND messages. 397 The new "Registration for xcast Address Supported" (X) flag indicates 398 to the 6LN that the 6LR accepts unicast, multicast, and anycast 399 address registrations as specified in this document and will ensure 400 that packets for the Registered Address will be routed to the 6LNs 401 that registered with the R flag set appropriately. 403 Figure 2 illustrates the X flag in its suggested position (8, 404 counting 0 to 15 in network order in the 16-bit array), to be 405 confirmed by IANA. 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Type | Length = 1 | Reserved |X|A|D|L|B|P|E|G| 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Reserved | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 Figure 2: New Capability Bits in the 6CIO 417 New Option Field: 419 X 1-bit flag: "Registration for Unicast, Multicast, and Anycast 420 Addresses Supported" 422 5. Updating RFC 6550 424 5.1. Updating MOP 3 426 RPL supports multicast operations in the "Storing Mode of Operation 427 with multicast support" (MOP 3) which provides source-independent 428 multicast routing in RPL, as prescribed in section 12 of [RFC6550]. 429 MOP 3 is a storing Mode of Operation. This operation builds a 430 multicast tree within the RPL DODAG for each multicast address. This 431 specification provides additional details for the MOP 3 operation. 433 The expectation in MOP 3 is that the unicast traffic also follows the 434 Storing Mode of Operation. But this is rarely the case in LLN 435 deployments of RPL where the "Non-Storing Mode of Operation" (MOP 1) 436 is the norm. Though it is preferred to build separate RPL Instances, 437 one in MOP 1 and one in MOP 3, this specification allows to hybrid 438 the Storing Mode for multicast and Non-Storing Mode for unicast in 439 the same RPL Instance, more in Section 10. 441 Though it was implicit in [RFC6550], this specification clarifies 442 that the freshness comparison based on the TID field is ignored for 443 RPL multicast operations. A RPL router maintains a remaining Path 444 Lifetime for each DAO that it receives for a multicast target, and 445 sends it own DAO for that target with the longest remaining lifetime 446 across its listening children. 448 5.2. New Non-Storing Multicast MOP 450 This specification adds a "Non-Storing Mode of Operation with ingress 451 replication multicast support" (MOP to be assigned by IANA) whereby 452 the non-storing Mode DAO to the Root may advertise a multicast 453 address in the RPL Target Option (RTO), whereas the Transit 454 Information Option (TIO) cannot. 456 In that mode, the RPL Root performs an ingress replication (IR) 457 operation on the multicast packets, meaning that it transmits one 458 copy of each multicast packet to each 6LR that is a transit for the 459 multicast target, using the same source routing header and 460 encapsulation as it would for a unicast packet for a RPL Unaware Leaf 461 (RUL) attached to that 6LR. 463 For the intermediate routers, the packet appears as any source routed 464 unicast packet. The difference shows only at the 6LR, that 465 terminates the source routed path and forwards the multicast packet 466 to all 6LNs that registered for the multicast address. 468 For a packet that is generated by the Root, this means that the Root 469 builds a source routing header as shown in section 8.1.3 of 470 [RFC9008], but for which the last and only the last address is 471 multicast. For a packet that is not generated by the Root, the Root 472 encapsulates the multicast packet as per section 8.2.4 of [RFC9008]. 473 In that case, the outer header is purely unicast, and the 474 encapsulated packet is purely multicast. 476 As with MOP 3, the freshness comparison based on the TID field is 477 ignored for RPL MOP 5 multicast operations. The Root maintains a 478 remaining Path Lifetime for each DAO that it receives, and the 6LRs 479 generate the DAO for multicast addresses with the longest remaining 480 lifetime across its registered 6LNs. 482 The route disappears when the associated path lifetime in the transit 483 option times out, but the procedure to remove a unicast route based 484 on TID cannot apply to multicast and anycast. 486 For this new mode as well, this specification allows to enable the 487 operation in a MOP 1 brown field, more in Section 10. 489 5.3. RPL Anycast Operation 491 With multicast, the address has a recognizable format, and a 492 multicast packet is to be delivered to all the active subscribers. 493 In contrast, the format of an anycast address is not distinguishable 494 from that of unicast. A legacy node may issue a DAO message without 495 setting the A flag, the unicast behavior may apply to anycast traffic 496 in a subDAGs. That message will be undistinguishable from a unicast 497 advertisement and the anycast behavior in the dataplane can only 498 happen if all the nodes that advertise the same anycast address are 499 synchronized with the same TID. That way, the multiple paths can 500 remain in the RPL DODAG. 502 With the A flag, this specification alleviates the issue of 503 synchronizing the TIDs, and as for multicast, the freshness 504 comparison based on the TID field is ignored. A target is routed as 505 anycast by a parent (or the Root) that received at least one DAO 506 message for that target with the A flag set to 1. 508 As opposed to multicast, the anycast operation described therein 509 applies to both addresses and prefixes, and the A flag can be set for 510 both. An external destination (address or prefix) that may be 511 injected as a RPL target from multiple border routers SHOULD be 512 injected as anycast in RPL to enable load balancing. A mobile target 513 that is multihomed SHOULD in contrast be advertised as unicast over 514 the multiple interfaces to favor the TID comparison and vs. the 515 multipath load balancing. 517 For either multicast and anycast, there can be multiple registrations 518 from multiple parties, each using a different value of the ROVR field 519 that identifies the individual registration. The 6LR MUST maintain a 520 registration state per value of the ROVR per multicast or anycast 521 address, but inject the route into RPL only once for each address, 522 and in the case of a multicast address, only if its scope is larger 523 than link-scope (3 or more). Since the registrations are considered 524 separate, the check on the TID that acts as registration sequence 525 only applies to the registration with the same ROVR. 527 The 6LRs that inject multicast and anycast routes into RPL may not be 528 synchronized to advertise same value of the Path Sequence in the RPL 529 TIO. It results that the value the Path Sequence is irrelevant when 530 the target is anycast or multicast, and that it MUST be ignored. 532 Like the 6LR, a RPL router in Storing Mode propagates the route to 533 its parent(s) in DAO messages once and only once for each address, 534 but it MUST retain a routing table entry for each of the children 535 that advertised the address. 537 When forwarding multicast packets down the DODAG, the RPL router 538 copies all the children that advertised the address in their DAO 539 messages. In contrast, when forwarding anycast packets down the 540 DODAG, the RPL router MUST copy one and only one of the children that 541 advertised the address in their DAO messages, and forward to one 542 parent if there is no such child. 544 5.4. New RPL Target Option Flags 546 [RFC6550] recognizes a multicast address by its format (as specified 547 in section 2.7 of [RFC4291]) and applies the specified multicast 548 operation if the address is recognized as multicast. This 549 specification updates [RFC6550] to add the M and A flags to the RTO 550 to indicate that the target address is to be processed as multicast 551 or anycast, respectively. 553 An RTO that has the M flag set to 1 is called a multicast RTO. An 554 RTO that has the A flag set to 1 is called an anycast RTO. An RTO 555 that has both the A and the M flags set to 0 is called an unicast 556 RTO. With this specification, the M and A flags are mutually 557 exclusive and MUST NOT be both set to 1. The capability to set both 558 flags is reserved and an RTO that is received with both flags set 559 MUST be ignored. 561 The suggested position for the A and M flags are 2 and 3 counting 562 from 0 to 7 in network order as shown in Figure 3, based on figure 4 563 of [RFC9010] which defines the flags in position 0 and 1: 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Type = 0x05 | Option Length |F|X|A|M|ROVRsz | Prefix Length | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | | 571 | Target Prefix (Variable Length) | 572 . . 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | | 575 ... Registration Ownership Verifier (ROVR) ... 576 | | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 Figure 3: Format of the RPL Target Option 581 6. Updating RFC 8505 583 6.1. New EARO flag 585 Section 4.1 of [RFC8505] defines the EARO as an extension to the ARO 586 option defined in [RFC6775]. 588 This specification adds a new M flag to the EARO flags field to 589 signal that the Registered Address is a multicast address. When both 590 the M and the R flags are set, the 6LR that conforms to this 591 specification joins the multicast stream, e.g., by injecting the 592 address in the RPL multicast support which is extended in this 593 specification for Non-Storing Mode. 595 This specification adds a new A flag to the EARO flags field to 596 signal that the Registered Address is an anycast address. When both 597 the A and the R flags are set, the 6LR that conforms to this 598 specification injects the anycast address in the RPL anycast support 599 that is introduced in this specification for both Storing and Non- 600 Storing Modes. 602 Figure 4 illustrates the A and M flags in their suggested positions 603 (2 and 3, respectively, counting 0 to 7 in network order in the 8-bit 604 array), to be confirmed by IANA. 606 0 1 2 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Type | Length | Status | Opaque | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 |Rsv|A|M| I |R|T| TID | Registration Lifetime | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | | 614 ... Registration Ownership Verifier ... 615 | | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 Figure 4: EARO Option Format 620 New and updated Option Fields: 622 Rsv 2-bit field: reserved, MUST be set to 0 and ignored by the 623 receiver 625 A 1-bit flag: "Registration for Anycast Address" 627 M 1-bit flag: "Registration for Multicast Address" 629 6.2. New EDAR Message Flag field 631 Section 4 of [RFC6775] provides the same format for DAR and DAC 632 messages but the status field is only used in DAC message and has to 633 set to zero in DAC messages. [RFC8505] extends the DAC message as an 634 EDAC but does not change the status field in the EDAR. 636 This specification repurposes the status field in the EDAR and a 637 Flags field. It adds a new M flag to the EDAR flags field to signal 638 that the Registered Address is a multicast address and a new A flag 639 to signal that the Registered Address is an anycast address. As for 640 EARO, the flags are mutually exclusive. 642 Figure 5 illustrates the A and M flags in their suggested positions 643 (0 and 1, respectively, counting 0 to 7 in network order in the 8-bit 644 array), to be confirmed by IANA. 646 0 1 2 3 647 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 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Type |CodePfx|CodeSfx| Checksum | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 |A|M| Reserved | TID | Registration Lifetime | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | | 654 ... Registration Ownership Verifier (ROVR) ... 655 | | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | | 658 + + 659 | | 660 + Registered Address + 661 | | 662 + + 663 | | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 Figure 5: Extended Duplicate Address Message Format 668 New and updated Option Fields: 670 Reserved 6-bit field: reserved, MUST be set to 0 and ignored by the 671 receiver 673 A 1-bit flag: "Registration for Anycast Address" 675 M 1-bit flag: "Registration for Multicast Address" 677 6.3. Registering Extensions 679 With [RFC8505]: 681 * A router that expects to reboot may send a final RA message, upon 682 which nodes should register elsewhere or reregister to this router 683 upon reboot. In all other cases, a node reboot is silent. When 684 the node comes back to life, existing registration state might be 685 lost if it was not persisted, e.g., in persistent memory. 687 * Only unicast addresses can be registered. 689 * The 6LN must register all its ULA and GUA with a NS(EARO). 691 * The 6LN may set the R flag in the EARO to obtain return 692 reachability services by the 6LR, e.g., through ND proxy 693 operations, or by injecting the route in a route-over subnet. 695 * the 6LR maintains a registration state per Registered Address, 696 including an NCE with the Link Layer Address (LLA) of the 697 Registered Node (the 6LN here). 699 This specification adds the following behavior: 701 * A new ARO Status is introduced to indicate a "Registration Refresh 702 Request" (see Table 7). 704 This status is used in asynchronous NA(EARO) messages to indicate 705 to peer 6LNs that they are requested to reregister all addresses 706 that were previously registered to the originating node. The NA 707 message may be sent to a unicast or a multicast link-scope address 708 and should be contained within the L2 range where nodes may 709 effectively register to this, e.g., a radio broadcast domain. 711 A device that wishes to refresh its state, e.g., upon reboot if it 712 may have lost some registration state, may send an asynchronous 713 NA(EARO) with this new status value. That asynchronous NA(ARO) 714 SHOULD be sent to the all-nodes link scope multicast address 715 (FF02::1) and Target MUST be set to the link local address that 716 was exposed previously by this node to accept registrations, and 717 the TID MUST be set to 0. 719 In an unreliable environment, the multicast NA(EARO) message may 720 be resent in a fast sequence, in which case the TID must be 721 incremented each time. A 6LN that has recently processed the 722 NA(ARO) ignores the NA(EARO) with a newer TID received within the 723 duration of the fast sequence. That duration depends on the 724 environent and has to be configured. By default, it is of 10 725 seconds. 727 * A new IPv6 ND Node Uptime option (NUO) is introduced to be placed 728 in IPv6 ND messages. The NUO carries a Node State Sequence 729 Information (NSSI) and a Node Uptime. See Section 9 for the 730 option details. 732 A node that receives the NUO checks whether it is indicative of a 733 loss of state, such as an address registration, in the sender. If 734 so, it may attempt to reform the state, e.g., by re-registering an 735 address. A loss of state is inferred if the NSSI has changed 736 since last sight, or the Node Uptime is less than the time since 737 the state was installed. 739 * Registration for multicast and anycast addresses is now supported. 740 New flags are added to the EARO to signal when the registered 741 address is anycast or multicast. 743 * The Status field in the EDAR message that was reserved and not 744 used in RFC 8505 is repurposed to transport the flags to signal 745 multicast and anycast. 747 * The 6LN MUST also register all the IPv6 multicast addresses that 748 it listens to but the all-nodes link-scope multicast address 749 FF02::1 [RFC4291] which is implicitly registered, and it MUST set 750 the M flag in the EARO for those addresses. 752 * The 6LN MAY set the R flag in the EARO to obtain the delivery of 753 the multicast packets by the 6LR, e.g., by MLD proxy operations, 754 or by injecting the address in a route-over subnet or in the 755 Protocol Independent Multicast [RFC7761] protocol. 757 * The 6LN MUST also register all the IPv6 anycast addresses that it 758 supports and it MUST set the A flag in the EARO for those 759 addresses. 761 * The 6LR and the 6LBR are extended to accept more than one 762 registration for the same address when it is anycast or multicast, 763 since multiple 6LNs may subscribe to the same address of these 764 types. In both cases, the Registration Ownership Verifier (ROVR) 765 in the EARO identifies uniquely a registration within the 766 namespace of the Registered Address. 768 * The 6LR MUST also consider that all the nodes that registered an 769 address to it (as known by the SLLAO) also registered to the all 770 nodes link-scope multicast address FF02::1 [RFC4291]. 772 * The 6LR MUST maintain a registration state per tuple (IPv6 773 address, ROVR) for both anycast and multicast types of address. 774 It SHOULD notify the 6LBR with an EDAR message, unless it 775 determined that the 6LBR is legacy and does not support this 776 specification. In turn, the 6LBR MUST maintain a registration 777 state per tuple (IPv6 address, ROVR) for both anycast and 778 multicast types of address. 780 7. Updating RFC 9010 782 With [RFC9010]: 784 * The 6LR injects only unicast routes in RPL 786 * Upon a registration with the R flag set to 1 in the EARO, the 6LR 787 injects the address in the RPL unicast support. 789 * Upon receiving a packet directed to a unicast address for which it 790 has an active registration, the 6LR delivers the packet as a 791 unicast layer-2 frame to the LLA the nodes that registered the 792 unicast address. 794 This specification adds the following behavior: 796 * Upon a registration with the R and the M flags set to 1 in the 797 EARO, if the scope of the multicast address is above link-scope 798 [RFC7346], then the 6LR injects the address in the RPL multicast 799 support and sets the M flag in the RTO. 801 * Upon a registration with the R and the A flags set to 1 in the 802 EARO, the 6LR injects the address in the new RPL anycast support 803 and sets the A flag in the RTO. 805 * Upon receiving a packet directed to a multicast address for which 806 it has at least one registration, the 6LR delivers a copy of the 807 packet as a unicast layer-2 frame to the LLA of each of the nodes 808 that registered to that multicast address. 810 * Upon receiving a packet directed to a multicast address for which 811 it has at least one registration, the 6LR delivers a copy of the 812 packet as a unicast layer-2 frame to the LLA of exactly one of the 813 nodes that registered to that multicast address. 815 8. Leveraging RFC 8928 817 Address-Protected Neighbor Discovery for Low-Power and Lossy Networks 818 [RFC8928] was defined to protect the ownership of unicast IPv6 819 addresses that are registered with [RFC8505]. 821 With [RFC8928], it is possible for a node to autoconfigure a pair of 822 public and private keys and use them to sign the registration of 823 addresses that are either autoconfigured or obtained through other 824 methods. 826 The first hop router (the 6LR) may then validate a registration and 827 perform source address validation on packets coming from the sender 828 node (the 6LN). 830 Anycast and multicast addresses are not owned by one node. Multiple 831 nodes may subscribe to the same address. Also, anycast and multicast 832 addresses are not used to source traffic. In that context, the 833 method specified in [RFC8928] cannot be used with autoconfigured 834 keypairs to protect a single ownership. 836 For an anycast or a multicast address, it is still possible to 837 leverage [RFC8928] to enforce the right to subscribe. A keypair MUST 838 be associated with the address before it is deployed, and a ROVR MUST 839 be generated from that keypair as specified in [RFC8928]. The 840 address and the ROVR MUST then be installed in the 6LBR so it can 841 recognize the address and compare the ROVR on the first registration. 843 The keypair MUST then be provisioned in each node that needs to 844 subscribe to the anycast or multicast address, so the node can follow 845 the steps in [RFC8928] to register the address. 847 9. Node Uptime Option 849 This specification introduces a new option that characterizes the 850 uptime of the sender. The option may be used by routers in RA 851 messages and by any node in NA, NA, and RS messages. It is used by 852 the receiver to infer whether some state synchronization might be 853 lost, e.g., due to reboot. 855 0 1 2 3 856 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 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | Type | Length | Checksum | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 |S| flags | NSSI | Exponent | Uptime Mantissa | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 Figure 6: Node Uptime Option Format 865 Type To be assigned by IANA, see Table 8 867 Length 1 868 S 1-bit flag, set to indicate that the device is low-power and may 869 sleep. 871 flags 5-bit, reserved. MUST be set to 0 by the sender and ignored 872 by the receiver. 874 NSSI 10-bits unsigned integer: The Node State Sequence Information 876 Uptime Exponent 6-bits unsigned integer: The 2-exponent of the 877 uptime unit 879 Uptime Mantissa 10-bits unsigned integer: The mantissa of the uptime 880 value 882 The Node Uptime indicates how long the sender has been continuously 883 up and running without loss of state. It is expressed by the Uptime 884 Mantissa in units of 2 at the power of the Uptime Exponent 885 milliseconds. 887 The initial value and the steps of the Uptime Exponent are chosen 888 freely by the implementation, but the value MUST NOT decrease over 889 time. This means that 2 expressions of time from the same node can 890 be compared by aggregating the Exponent + Mantissa Uptime fields and 891 considering the aggregate globally as a 16-bits unsigned integer. 893 +----------+----------+------------+-----------+ 894 | Mantissa | Exponent | Resolution | Uptime | 895 +----------+----------+------------+-----------+ 896 | 1 | 0 | 1ms | 1ms | 897 +----------+----------+------------+-----------+ 898 | 5 | 10 | 1s | 5 seconds | 899 +----------+----------+------------+-----------+ 900 | 2 | 15 | 30s | 1mn | 901 +----------+----------+------------+-----------+ 902 | 2 | 21 | 33mn | 1 hour | 903 +----------+----------+------------+-----------+ 905 Table 1: Node Uptime Rough Values 907 The NSSI SHOULD be stored by this node in persistent memory by the 908 sender and incremented when it reboots and lost state. When 909 persisting is not possible, then the NSSI is randomly generated upon 910 a loss of state. Any change in the value of the NSSI from a node is 911 an indication that the node lost state and that the needful state 912 should be reinstalled, e.g., addresses registered to that node should 913 be registered again with a minimal temporization to avoid collisions. 915 10. Deployment considerations 917 With this specification, a RPL DODAG forms a realm, and multiple RPL 918 DODAGs may federated in a single RPL Instance administratively. This 919 means that a multicast address that needs to span a RPL DODAG MUST 920 use a scope of Realm-Local whereas a multicast address that needs to 921 span a RPL Instance MUST use a scope of Admin-Local as discussed in 922 section 3 of "IPv6 Multicast Address Scopes" [RFC7346]. 924 "IPv6 Addressing of IPv4/IPv6 Translators" [RFC6052] enables to embed 925 IPv4 addresses in IPv6 addresses. The Root of a DODAG may leverage 926 that technique to translate IPv4 traffic in IPv6 and route along the 927 RPL domain. When encapsulating an packet with an IPv4 multicast 928 Destination Address, it MUST use a multicast address with the 929 appropriate scope, Realm-Local or Admin-Local. 931 "Unicast-Prefix-based IPv6 Multicast Addresses" [RFC3306] enables to 932 form 2^32 multicast addresses from a single /64 prefix. If an IPv6 933 prefix is associated to an Instance or a RPL DODAG, this provides a 934 namespace that can be used in any desired fashion. It is for 935 instance possible for a standard defining organization to form its 936 own registry and allocate 32-bit values from that namespace to 937 network functions or device types. When used within a RPL deployment 938 that is associated with a /64 prefix the IPv6 multicast addresses can 939 be automatically derived from the prefix and the 32-bit value for 940 either a Realm-Local or an Admin-Local multicast address as needed in 941 the configuration. 943 IN a "green field" deployment where all nodes support this 944 specification, it is possible to deploy a single RPL Instance using a 945 multicast MOP for unicast, multicast and anycast addresses. 947 In a "brown field" where legacy devices that do not support this 948 specification co-exist with upgraded devices, it is RECOMMENDED to 949 deploy one RPL Instance in any Mode of Operation (typically MOP 1) 950 for unicast that legacy nodes can join, and a separate RPL Instance 951 dedicated to multicast and anycast operations using a multicast MOP. 953 To deploy a Storing Mode multicast operation using MOP 3 in a RPL 954 domain, it is required that there is enough density of RPL routers 955 that support MOP 3 to build a DODAG that covers all the potential 956 listeners and include the spanning multicast trees that are needed to 957 distribute the multicast flows. This might not be the case when 958 extending the capabilities of an existing network. 960 In the case of the new Non-Storing multicast MOP, arguably the new 961 support is only needed at the 6LRs that will accept multicast 962 listeners. It is still required that each listener can reach at 963 least one such 6LR, so the upgraded 6LRs must be deployed to cover 964 all the 6LN that need multicast services. 966 Using separate RPL Instances for in the one hand unicast traffic and 967 in the other hand anycast and multicast traffic allows to use 968 different objective function, one favoring the link quality up for 969 unicast collection and one favoring downwards link quality for 970 multicast distribution. 972 But this might be impractical in some use cases where the signaling 973 and the state to be installed in the devices are very constrained, 974 the upgraded devices are too sparse, or the devices do not support 975 more multiple instances. 977 When using a single RPL Instance, MOP 3 expects the Storing Mode of 978 Operation for both unicast and multicast, which is an issue in 979 constrained networks that typically use MOP 1 for unicast. This 980 specification allows a mixed mode that is signaled as MOP 1 in the 981 DIO messages for backward compatibility, where limited multicast and/ 982 or anycast is available, under the following conditions: 984 * There MUST be enough density of 6LRs that support the mixed mode 985 to cover the all the 6LNs that require multicast or anycast 986 services. In Storing Mode, there MUST be enough density or 6LR 987 that support the mixed mode to also form a DODAG to the Root. 989 * The RPL routers that support the mixed mode and are configured to 990 operate in in accordance with the desired operation in the 991 network. 993 * The MOP signaled in the RPL DODAG Information Object (DIO) 994 messages is MOP 1 to enable the legacy nodes to operate as leaves. 996 * The support of multicast and/or anycast in the RPL Instance SHOULD 997 be signaled by the 6LRs to the 6LN using a 6CIO, see Section 4. 999 * Alternatively, the support of multicast in the RPL domain can be 1000 globally known by other means such as configuration or external 1001 information such as support of a version of an industry standard 1002 that mandates it. In that case, all the routers MUST support the 1003 mixed mode. 1005 11. Security Considerations 1007 This specification extends [RFC8505], and the security section of 1008 that document also applies to this document. In particular, the link 1009 layer SHOULD be sufficiently protected to prevent rogue access. 1011 Section 8 leverages [RFC8928] to prevent an unwanted subscriber to 1012 register for an anycast of a multicast address. This mechanism comes 1013 with a keypair that is shared between all subscribers. A shared key 1014 is prone to be stolen and the level of protection can only go down 1015 with time. 1017 It is possible to update the keys associated to an address in all the 1018 6LNs, but the flow is not clearly documented and may not complete in 1019 due time for all nodes in LLN use cases. It may be simpler to 1020 install a all-new address with new keys over a period of time, and 1021 switch the traffic to that address when the migration is complete. 1023 12. Backward Compatibility 1025 A legacy 6LN will not register multicast addresses and the service 1026 will be the same when the network is upgraded. A legacy 6LR will not 1027 set the M flag in the 6CIO and an upgraded 6LN will not register 1028 multicast addresses. 1030 Upon an EDAR message, a legacy 6LBR may not realize that the address 1031 being registered is anycast or multicast, and return that it is 1032 duplicate in the EDAC status. The 6LR MUST ignore a duplicate status 1033 in the EDAR for anycast and multicast addresses. 1035 As detailed in Section 10, it is possible to add multicast on an 1036 existing MOP 1 deployment. 1038 The combination of a multicast address and the M flag set to 0 in an 1039 RTO in a MOP 3 RPL Instance is understood by the receiver that 1040 supports this specification (the parent) as an indication that the 1041 sender (child) does not support this specification, but the RTO is 1042 accepted and processed as if the M flag was set for backward 1043 compatibility. 1045 When the DODAG is operated in MOP 3, a legacy node will not set the M 1046 flag and still expect multicast service as specified in section 12 of 1047 [RFC6550]. In MOP 3 an RTO that is received with a target that is 1048 multicast and the M bit set to 0 MUST be considered as multicast and 1049 MUST be processed as if the M flag is set. 1051 13. IANA Considerations 1053 Note to RFC Editor, to be removed: please replace "This RFC" 1054 throughout this document by the RFC number for this specification 1055 once it is allocated. Also, the I Field is defined in [RFC9010] but 1056 is missing from the subregistry, so the bit positions must be added 1057 for completeness. 1059 IANA is requested to make changes under the "Internet Control Message 1060 Protocol version 6 (ICMPv6) Parameters" [IANA.ICMP] and the "Routing 1061 Protocol for Low Power and Lossy Networks (RPL)" [IANA.RPL] 1062 registries, as follows: 1064 13.1. New EDAR Message Flags Subregistry 1066 IANA is requested to create a new "EDAR Message Flags" subregistry of 1067 the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" 1068 registry as indicated in Table 2: 1070 +---------------+---------------------------------------+-----------+ 1071 | Bit Number | Meaning | Reference | 1072 +---------------+---------------------------------------+-----------+ 1073 | 0 (suggested) | A flag: Registered | This RFC | 1074 | | Address is Anycast | | 1075 +---------------+---------------------------------------+-----------+ 1076 | 1 (suggested) | M flag: Registered | This RFC | 1077 | | Address is Multicast | | 1078 +---------------+---------------------------------------+-----------+ 1080 Table 2: EDAR Message flags 1082 13.2. New EARO flags 1084 IANA is requested to make additions to the "Address Registration 1085 Option Flags" [IANA.ICMP.ARO.FLG] of the "Internet Control Message 1086 Protocol version 6 (ICMPv6) Parameters" registry as indicated in 1087 Table 3: 1089 +---------------+-----------------------+-----------+ 1090 | ARO flag | Meaning | Reference | 1091 +---------------+-----------------------+-----------+ 1092 | 2 (suggested) | A flag: Registration | This RFC | 1093 | | for Anycast Address | | 1094 +---------------+-----------------------+-----------+ 1095 | 3 (suggested) | M flag: Registration | This RFC | 1096 | | for Multicast Address | | 1097 +---------------+-----------------------+-----------+ 1098 | 4 and 5 | "I" Field | RFC 8505 | 1099 +---------------+-----------------------+-----------+ 1101 Table 3: New ARO flags 1103 13.3. New RTO flags 1105 IANA is requested to make additions to the "RPL Target Option Flags" 1106 [IANA.RPL.RTO.FLG] subregistry of the "Routing Protocol for Low Power 1107 and Lossy Networks (RPL)" registry as indicated in Table 4: 1109 +---------------+---------------------------------------+-----------+ 1110 | Bit Number | Meaning | Reference | 1111 +---------------+---------------------------------------+-----------+ 1112 | 2 (suggested) | A flag: Registered | This RFC | 1113 | | Address is Anycast | | 1114 +---------------+---------------------------------------+-----------+ 1115 | 3 (suggested) | M flag: Registered | This RFC | 1116 | | Address is Multicast | | 1117 +---------------+---------------------------------------+-----------+ 1119 Table 4: New RTO flags 1121 13.4. New RPL Mode of Operation 1123 IANA is requested to make an addition to the "Mode of Operation" 1124 [IANA.RPL.MOP] subregistry of the "Routing Protocol for Low Power and 1125 Lossy Networks (RPL)" registry as indicated in Table 5: 1127 +---------------+---------------------------------------+-----------+ 1128 | Value | Description | Reference | 1129 +---------------+---------------------------------------+-----------+ 1130 | 5 | Non-Storing Mode of Operation with | This RFC | 1131 | (suggested) | ingress replication multicast support | | 1132 +---------------+---------------------------------------+-----------+ 1134 Table 5: New RPL Mode of Operation 1136 13.5. New 6LoWPAN Capability Bits 1138 IANA is requested to make an addition to the "6LoWPAN Capability 1139 Bits" [IANA.ICMP.6CIO] subregistry subregistry of the "Internet 1140 Control Message Protocol version 6 (ICMPv6) Parameters" registry as 1141 indicated in Table 6: 1143 +-------------+-----------------------------+-----------+ 1144 | Capability | Meaning | Reference | 1145 | Bit | | | 1146 +-------------+-----------------------------+-----------+ 1147 | 8 | X flag: Registration for | This RFC | 1148 | (suggested) | Unicast, Multicast, and | | 1149 | | Anycast Addresses Supported | | 1150 +-------------+-----------------------------+-----------+ 1152 Table 6: New 6LoWPAN Capability Bits 1154 13.6. New Address Registration Option Status Values 1156 IANA has made additions to the "Address Registration Option Status 1157 Values" subregistry under the "Internet Control Message Protocol 1158 version 6 (ICMPv6) Parameters" registry, as follows: 1160 +----------------+------------------------------+-----------+ 1161 | Value | Description | Reference | 1162 +----------------+------------------------------+-----------+ 1163 | 11 (suggested) | Registration Refresh Request | This RFC | 1164 +----------------+------------------------------+-----------+ 1166 Table 7: New Address Registration Option Status Values" 1168 13.7. New IPv6 Neighbor Discovery Option 1170 IANA has made additions to the "IPv6 Neighbor Discovery Option 1171 Formats" subregistry under the "Internet Control Message Protocol 1172 version 6 (ICMPv6) Parameters" registry, as follows: 1174 +----------------+--------------------+-----------+ 1175 | Value | Description | Reference | 1176 +----------------+--------------------+-----------+ 1177 | 42 (suggested) | Node Uptime Option | This RFC | 1178 +----------------+--------------------+-----------+ 1180 Table 8: New IPv6 Neighbor Discovery Option" 1182 14. Acknowledgments 1184 15. Normative References 1186 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1187 Requirement Levels", BCP 14, RFC 2119, 1188 DOI 10.17487/RFC2119, March 1997, 1189 . 1191 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 1192 Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306, 1193 August 2002, . 1195 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1196 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1197 2006, . 1199 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1200 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1201 DOI 10.17487/RFC4861, September 2007, 1202 . 1204 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1205 Address Autoconfiguration", RFC 4862, 1206 DOI 10.17487/RFC4862, September 2007, 1207 . 1209 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1210 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1211 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1212 Low-Power and Lossy Networks", RFC 6550, 1213 DOI 10.17487/RFC6550, March 2012, 1214 . 1216 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1217 Bormann, "Neighbor Discovery Optimization for IPv6 over 1218 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1219 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1220 . 1222 [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, 1223 DOI 10.17487/RFC7346, August 2014, 1224 . 1226 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 1227 IPv6 over Low-Power Wireless Personal Area Networks 1228 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 1229 2014, . 1231 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1232 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1233 May 2017, . 1235 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1236 (IPv6) Specification", STD 86, RFC 8200, 1237 DOI 10.17487/RFC8200, July 2017, 1238 . 1240 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 1241 Perkins, "Registration Extensions for IPv6 over Low-Power 1242 Wireless Personal Area Network (6LoWPAN) Neighbor 1243 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 1244 . 1246 [RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik, 1247 "Address-Protected Neighbor Discovery for Low-Power and 1248 Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November 1249 2020, . 1251 [RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL 1252 (Routing Protocol for Low-Power and Lossy Networks) 1253 Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021, 1254 . 1256 [IANA.ICMP] 1257 IANA, "IANA Registry for ICMPv6", IANA, 1258 https://www.iana.org/assignments/icmpv6-parameters/ 1259 icmpv6-parameters.xhtml. 1261 [IANA.ICMP.ARO.FLG] 1262 IANA, "IANA Sub-Registry for the ARO Flags", IANA, 1263 https://www.iana.org/assignments/icmpv6-parameters/ 1264 icmpv6-parameters.xhtml#icmpv6-adress-registration-option- 1265 flags. 1267 [IANA.ICMP.6CIO] 1268 IANA, "IANA Sub-Registry for the 6LoWPAN Capability Bits", 1269 IANA, https://www.iana.org/assignments/icmpv6-parameters/ 1270 icmpv6-parameters.xhtml#sixlowpan-capability-bits. 1272 [IANA.RPL] IANA, "IANA Registry for the RPL", 1273 IANA, https://www.iana.org/assignments/rpl/rpl.xhtml. 1275 [IANA.RPL.RTO.FLG] 1276 IANA, "IANA Sub-Registry for the RTO Flags", IANA, 1277 https://www.iana.org/assignments/rpl/rpl.xhtml#rpl-target- 1278 option-flags. 1280 [IANA.RPL.MOP] 1281 IANA, "IANA Sub-Registry for the RPL Mode of Operation", 1282 IANA, https://www.iana.org/assignments/rpl/rpl.xhtml#mop. 1284 16. Informative References 1286 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1287 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1288 DOI 10.17487/RFC3810, June 2004, 1289 . 1291 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1292 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1293 Overview, Assumptions, Problem Statement, and Goals", 1294 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1295 . 1297 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1298 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1299 DOI 10.17487/RFC6282, September 2011, 1300 . 1302 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 1303 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 1304 February 2016, . 1306 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 1307 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 1308 Multicast - Sparse Mode (PIM-SM): Protocol Specification 1309 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 1310 2016, . 1312 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1313 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1314 DOI 10.17487/RFC6052, October 2010, 1315 . 1317 [RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI 1318 Option Type, Routing Header for Source Routes, and IPv6- 1319 in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, 1320 DOI 10.17487/RFC9008, April 2021, 1321 . 1323 [I-D.ietf-bess-evpn-optimized-ir] 1324 Rabadan, J., Sathappan, S., Lin, W., Katiyar, M., and A. 1325 Sajassi, "Optimized Ingress Replication Solution for 1326 Ethernet VPN (EVPN)", Work in Progress, Internet-Draft, 1327 draft-ietf-bess-evpn-optimized-ir-12, 25 January 2022, 1328 . 1331 [Wi-SUN] Heile, B., (Remy), B. L., Zhang, M., and C. E. Perkins, 1332 "Wi-SUN FAN Overview", Work in Progress, Internet-Draft, 1333 draft-heile-lpwan-wisun-overview-00, 3 July 2017, 1334 . 1337 [I-D.thubert-bess-secure-evpn-mac-signaling] 1338 Thubert, P., Przygienda, T., and J. Tantsura, "Secure EVPN 1339 MAC Signaling", Work in Progress, Internet-Draft, draft- 1340 thubert-bess-secure-evpn-mac-signaling-03, 31 January 1341 2022, . 1344 [IEEE Std 802.15.4] 1345 IEEE standard for Information Technology, "IEEE Std 1346 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 1347 and Physical Layer (PHY) Specifications for Low-Rate 1348 Wireless Personal Area Networks". 1350 [IEEE Std 802.11] 1351 IEEE standard for Information Technology, "IEEE Standard 1352 802.11 - IEEE Standard for Information Technology - 1353 Telecommunications and information exchange between 1354 systems Local and metropolitan area networks - Specific 1355 requirements - Part 11: Wireless LAN Medium Access Control 1356 (MAC) and Physical Layer (PHY) Specifications.", 1357 . 1359 [IEEE Std 802.15.1] 1360 IEEE standard for Information Technology, "IEEE Standard 1361 for Information Technology - Telecommunications and 1362 Information Exchange Between Systems - Local and 1363 Metropolitan Area Networks - Specific Requirements. - Part 1364 15.1: Wireless Medium Access Control (MAC) and Physical 1365 Layer (PHY) Specifications for Wireless Personal Area 1366 Networks (WPANs)". 1368 Author's Address 1369 Pascal Thubert (editor) 1370 Cisco Systems, Inc 1371 Building D 1372 45 Allee des Ormes - BP1200 1373 06254 Mougins - Sophia Antipolis 1374 France 1375 Phone: +33 497 23 26 34 1376 Email: pthubert@cisco.com