-
Notifications
You must be signed in to change notification settings - Fork 3
/
6lo-multicast-registration.xml
1998 lines (1783 loc) · 94.7 KB
/
6lo-multicast-registration.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="utf-8"?>
<!--DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"-->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902"
tocInclude="true" indexInclude="true" obsoletes="" consensus="true"
submissionType="IETF" xml:lang="en" version="3" updates="4861, 6550, 6553, 8505, 9010"
docName="draft-ietf-6lo-multicast-registration-20" >
<front>
<title abbrev="Multicast and Anycast Subscription">IPv6 Neighbor Discovery Multicast and Anycast Address Listener Subscription</title>
<author initials='P' surname='Thubert' fullname='Pascal Thubert' role='editor'>
<address>
<postal>
<city>Roquefort-les-Pins</city>
<code>06330</code>
<country>France</country>
</postal>
<email>pascal.thubert@gmail.com</email>
</address>
</author>
<area>Internet</area>
<workgroup>6lo</workgroup>
<abstract>
<t>
This document updates the 6LoWPAN extensions to IPv6 Neighbor Discovery
(RFC 4861, RFC 8505, RFC 7400) to enable a listener to subscribe to an IPv6 anycast or
multicast address; the document updates the Routing Protocol for Low-Power and Lossy Networks (RFC 6550, RFC 6553) to add a
new Non-Storing Multicast Mode and a new support for anycast addresses in
Storing and Non-Storing Modes.
This document extends RFC 9010 to enable a 6LoWPAN Router to inject the anycast and
multicast addresses in RPL.
</t>
</abstract>
</front>
<middle>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="introduction"> <name>Introduction</name>
<t>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.
</t><t>
The <xref target="RFC6550">"Routing Protocol for Low Power
and Lossy Networks"</xref> (RPL) provides IPv6
<xref target="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 2 peers, whatever that would mean in each LLN.
</t><t>
This trades the quality of peer-to-peer (P2P) paths for a vastly reduced
amount of control traffic and routing state that would be required to
operate an any-to-any shortest path protocol. Additionally,
broken routes may be fixed lazily and on-demand, based on dataplane
inconsistency discovery, which avoids wasting energy in the proactive repair
of unused paths.
</t><t>
RPL uses Destination Advertisement Object (DAO) messages to establish
Downward routes. DAO messages are an optional feature for
applications that require point-to-multipoint (P2MP) or point-to-
point (P2P) traffic. RPL supports two modes of Downward traffic:
Storing (fully stateful) or Non-Storing (fully source routed); see
Section 9 of <xref target="RFC6550"/>. The mode is signaled in the
Mode of Operation (MOP) field in the DODAG Information Object (DIO)
messages and applies to the whole RPL Instance.
</t><t>
Any given RPL Instance is either storing or non-storing.
In both cases, P2P packets travel Up toward a DODAG root then Down to
the final destination (unless the destination is on the Upward
route). In the Non-Storing case, the packet will travel all the way
to a DODAG root before traveling Down. In the Storing case, the
packet may be directed Down towards the destination by a common
ancestor of the source and the destination prior to reaching a DODAG
root.
Section 12 of <xref target="RFC6550"/> details the "Storing Mode of
Operation with multicast support" with source-independent multicast
routing in RPL.
</t><t>
The classical "IPv6 Neighbor Discovery (IPv6 ND) Protocol"
<xref target="RFC4861"/> <xref target="RFC4862"/> was defined for serial
links and shared transit media such as Ethernet at a time when broadcast
was cheap on those media while memory for neighbor cache was expensive.
It was thus designed as a reactive protocol that relies on caching and
multicast operations for the Address Discovery (aka Lookup) and Duplicate Address Detection (DAD) 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.
</t><t>
The original 6LoWPAN ND, <xref target="RFC6775"> "Neighbor Discovery
Optimizations for 6LoWPAN networks"</xref>, was introduced to avoid the
excessive use of multicast messages and enable IPv6 ND for operations over
energy-constrained nodes.
<xref target="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 6LoWPAN Router(s) (6LR) that serve(s) it.
To that effect, <xref target="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 6LR.
</t><t>
<xref target="RFC8505"> "Registration Extensions for 6LoWPAN Neighbor
Discovery"</xref> updates <xref target="RFC6775"/> into a generic Address
Registration mechanism that can be used to access services such as routing
and ND proxy and introduces the Extended Address Registration Option (EARO)
for that purpose. This provides a routing-agnostic interface for a host to
request that the router injects a unicast IPv6 address in the local routing
protocol and provide return reachability for that address.
</t><t>
<xref target="RFC9010">"Routing for RPL Leaves"</xref> provides the router
counterpart of the mechanism for a host that implements
<xref target="RFC8505"/> to inject its unicast Unique Local Addresses (ULAs)
and Global Unicast Addresses (GUAs) in RPL.
But though RPL also provides multicast routing, 6LoWPAN ND supports only
the registration of unicast addresses and there is no equivalent of
<xref target="RFC9010"/> to specify the 6LR behavior upon the subscription
of one or more multicast address(es).
</t><t>
The <xref target="RFC3810">"Multicast Listener Discovery Version 2 (MLDv2)
for IPv6" </xref> enables the router to learn which node listens to which
multicast address, but as the classical IPv6 ND protocol, MLD relies on
multicasting Queries to all nodes, which is unfit for low power operations.
As for IPv6 ND, it makes sense to let the 6LNs control when and how they
maintain the state associated to their multicast addresses in the 6LR, e.g.,
during their own wake time. In the case of a constrained node that already
implements <xref target="RFC8505"/> for unicast reachability, it makes sense
to extend to that support to subscribe the multicast addresses they listen to.
</t><t>
This specification Extends <xref target="RFC8505"/> and <xref target="RFC9010"/>
to add the capability for the 6LN to subscribe anycast and multicast addresses
and for the 6LR to inject them in RPL when appropriate. Note that due to
the unreliable propagation of packets in the LLN, it cannot be guaranteed that
any given packet is delivered once and only once. If a breakage happens along
the preferred parent tree that is normally used for multicast forwarding,
the packet going up may be rerouted to an alternate parent, leading to potential
failures and duplications, whereas a packet going down will not be delivered
in the subtree. It is up to the Upper Layer Protocols to cope with both situations.
</t>
</section> <!-- end section = "Introduction" -->
<section> <name>Terminology</name>
<section anchor="bcp"><name>Requirements Language</name>
<t>
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
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
they appear in all capitals, as shown here.
</t>
<t>
In addition, the terms "Extends" and "Amends" are used as a more specific term for "Updates" per
<xref target="I-D.kuehlewind-update-tag" /> section 3 as follows:
</t>
<dl newline="false" indent="7" spacing="compact" >
<dt>Amends/Amended by:</dt>
<dd>This tag pair is used with an amending RFC that changes the amended RFC. This could include bug fixes, behavior changes etc. This is intended to specify mandatory changes to the protocol. The goal of this tag pair is to signal to anyone looking to implement the amended RFC that they MUST also implement the amending RFC. </dd>
<dt>Extends/Extended by:</dt>
<dd> This tag pair is used with an extending RFC that defines an optional addition to the extended RFC. This can be used by documents that use existing extension points or clarifications that do not change existing protocol behavior. This signals to implementers and protocol designers that there are changes to the extended RFC that they need to consider but not necessarily implement.</dd>
</dl>
</section> <!-- end section "Requirements Language" -->
<section anchor="lo"><name>References</name>
<t>
This document uses terms and concepts that are discussed in:
</t>
<ul>
<li> <xref target="RFC4861">"Neighbor Discovery for IP version 6"
</xref> and
<xref target="RFC4862">"IPv6 Stateless address Autoconfiguration"
</xref>,
</li>
<li> <xref target="RFC6550">Routing Protocol for Low-Power
and Lossy Networks</xref>,
</li>
<li> <xref target="RFC6775">Neighbor Discovery Optimization for Low-Power
and Lossy Networks</xref>, as well as
</li>
<li>
<xref target="RFC8505">
"Registration Extensions for 6LoWPAN Neighbor Discovery"</xref> and
</li>
<li>
<xref target="RFC9008">
"Using RPI Option Type, Routing Header for Source Routes,
and IPv6-in-IPv6 Encapsulation in the RPL Data Plane"</xref>.
</li>
</ul>
</section> <!-- end section "References" -->
<section anchor="acronyms"><name>Glossary</name>
<t> This document uses the following acronyms:</t>
<dl newline="false" indent="7" spacing="compact" >
<dt>6BBR</dt><dd> 6LoWPAN Backbone Router </dd>
<dt>6CIO</dt><dd> Capability Indication Option </dd>
<dt>6LBR</dt><dd> 6LoWPAN Border Router </dd>
<dt>6LN</dt><dd> 6LoWPAN Node </dd>
<dt>6LR</dt><dd> 6LoWPAN Router </dd>
<dt>AMC</dt><dd> Address Mapping Confirmation </dd>
<dt>AMR</dt><dd> Address Mapping Request</dd>
<dt>ARO</dt><dd> Address Registration Option</dd>
<dt>DAC</dt><dd> Duplicate Address Confirmation </dd>
<dt>DAD</dt><dd> Duplicate Address Detection </dd>
<dt>DAO</dt><dd> Destination Advertisement Object </dd>
<dt>DAR</dt><dd> Duplicate Address Request</dd>
<dt>DIO</dt><dd> DODAG Information Object </dd>
<dt>DMB</dt><dd> Direct MAC Broadcast </dd>
<dt>DODAG</dt><dd> Destination-Oriented Directed Acyclic Graph </dd>
<dt>EARO</dt><dd> Extended Address Registration Option</dd>
<dt>EDAC</dt><dd> Extended Duplicate Address Confirmation </dd>
<dt>EDAR</dt><dd> Extended Duplicate Address Request</dd>
<dt>IR</dt><dd> Ingress Replication </dd>
<dt>LLN</dt><dd> Low-Power and Lossy Network </dd>
<dt>MOP</dt><dd> Mode of Operation </dd>
<dt>NA</dt><dd> Neighbor Advertisement </dd>
<dt>NCE</dt><dd> Neighbor Cache Entry </dd>
<dt>ND</dt><dd> Neighbor Discovery </dd>
<dt>NS</dt><dd> Neighbor Solicitation </dd>
<dt>RA</dt><dd> Router Advertisement </dd>
<dt>ROVR</dt><dd> Registration Ownership Verifier, pronounced "rover" </dd>
<dt>RPL</dt><dd> Routing Protocol for Low-Power and Lossy Networks, pronounced "ripple" </dd>
<dt>RS</dt><dd> Router Solicitation </dd>
<dt>RTO</dt><dd> RPL Target Option </dd>
<dt>TID</dt><dd> Transaction ID </dd>
<dt>TIO</dt><dd> Transit Information Option </dd>
</dl>
</section> <!-- end section "Glossary" -->
<section anchor="terms"><name>New terms</name>
<t> This document introduces the following terms:</t>
<dl newline="false" indent="7" spacing="compact" >
<dt>Origin</dt><dd> The node that issued an anycast or multicast
advertisement, either in the form of an NS(EARO) or as a DAO(TIO, RTO) </dd>
<dt>Merge/merging</dt><dd> The action of receiving multiple anycast or
multicast advertisements, either internally from self, in the form of
an NS(EARO), or as a DAO(TIO, RTO), and generating a single DAO(TIO, RTO).
The RPL 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 multicast advertisements from different origins becomes the origin of the merged advertisement
and uses its own values for the Path Sequence and Registration Ownership Verifier (ROVR) fields.
</dd>
<dt>Subscribe/subscription</dt><dd> The special form of
registration that leverages NS(EARO) to register (subscribe to)
a multicast or an anycast address.
</dd>
</dl>
</section> <!-- end section "New terms" -->
</section> <!-- end section "Terminology" -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="overview"><name>Overview</name>
<t>
This specification Extends <xref target="RFC8505"/> and inherits from
<xref target="RFC8928"/> to provide a registration method - called
subscription in this case - for anycast and multicast address.
<xref target="RFC8505"/> is agnostic to the routing protocol in which the
address may be redistributed.
</t>
<t>
As opposed to unicast addresses, there might be multiple registrations from multiple parties for the same address. The router retains one registration per party per multicast or anycast address, but injects the route into the routing protocol only once for each address, asynchronously to the registration. On the other hand, the validation exchange with the registrar (6LBR) is still needed if the router checks the right for the host to listen to the anycast or multicast address.
</t>
<t>
<xref target="figSub"/> depicts the registration of an anycast or a multicast address.
As shown, the 6LBR receives and accepts multiple Extended DAR messages for the same address,
and the address being registered by multiple nodes is not treated as a duplication.
</t>
<figure anchor='figSub'><name> Registration Flow for an anycast or multicast Address</name>
<artwork><![CDATA[
6LoWPAN Node 6LR 6LBR
(host1) (router) (registrar)
| | |
| DMB link | |
| | |
| ND-Classic RS | |
|----------------->| |
|------------> | |
|------------------------> |
| ND-Classic RA | |
|<-----------------| |
| | |
| NS(EARO) | |
|----------------->| |
| | Extended DAR |
| |-------------->|
| | |
| | Extended DAC |
| |<--------------|
| NA(EARO) |
|<-----------------|<inject route> ->
| |
...
(host2) (router) 6LBR
| NS(EARO) | |
|----------------->| |
| | |
| | Extended DAR |
| |-------------->|
| | |
| | Extended DAC |
| |<--------------|
| NA(EARO) | |
|<-----------------| |
...
(host1) (router)
| NS(EARO) | |
|----------------->| |
| | |
| NA(EARO) | |
|<-----------------| |
...
| |<maintain route> ->
...
]]></artwork>
</figure>
<t>In classical networks, <xref target="RFC8505"/> may be used for an ND
proxy operation as specified in <xref target="RFC8929"/>, or redistributed in
a full-fledged routing protocol such as might be done in BGP for Ethernet
VPN <xref target="I-D.thubert-bess-secure-evpn-mac-signaling"/> or in
the Routing In Fat Trees (RIFT) protocol
<xref target="I-D.ietf-rift-rift"/>. The device mobility can be
gracefully supported as long as the routers can exchange and make sense of
the sequence counter in the TID field of the EARO.
</t>
<t> In the case of LLNs, RPL <xref target="RFC6550"/> is the routing protocol
of choice and <xref target="RFC9010"/> specifies how the unicast address
advertised with <xref target="RFC8505"/> is redistributed in RPL. This
specification also provides RPL extensions for anycast and multicast address
operation and redistribution. In the RPL case and unless specified otherwise,
the behavior of the 6LBR that acts as RPL Root, of the intermediate routers
down the RPL graph, of the 6LR that act as access routers and of the 6LNs
that are the RPL-unaware destinations, is the same as for unicast. In
particular, forwarding a packet happens as specified in section 11 of
<xref target="RFC6550"/>, including loop avoidance and detection, though in
the case of multicast multiple copies might be generated.
</t>
<t><xref target="RFC8505"/> is a pre-requisite to this specification.
A node that implements this MUST also implement <xref target="RFC8505"/>.
This specification modifies existing options and updates the associated
behaviors to enable the Registration for Multicast Addresses as an extension
to <xref target="RFC8505"/>.
As with the unicast address registration, the subscription to anycast and multicast
addresses between a node and its router(s) is agnostic (meaning, independent, unaware of)
to the routing protocol in which this information may be redistributed or aggregated
by the router to other routers, though protocol extensions would be needed in the protocol
when multicast services are not available.
</t>
<t>
This specification also Extends <xref target="RFC6550"/> and
<xref target="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 herein MUST also
implement <xref target="RFC9010"/>.
</t>
<t>
<xref target="figref"/> 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 maintains a registry of the active registrations as
an abstract data structure called an Address Registrar for 6LoWPAN ND.
</t>
<t>
The LLN may be a hub-and-spoke access link such as (Low-Power) Wi-Fi
<xref target="IEEE80211"/> and Bluetooth (Low Energy)
<xref target="IEEE802151"/>, or a Route-Over LLN such as the Wi-SUN
<xref target="I-D.heile-lpwan-wisun-overview"/> and 6TiSCH
<xref target="RFC9030"/> meshes that leverages 6LoWPAN
<xref target="RFC4919"/> <xref target="RFC6282"/>
and RPL <xref target="RFC6550"/> over <xref target="IEEE802154"/>.
</t>
<figure anchor="figref" align="center"><name>Wireless Mesh</name>
<artwork><![CDATA[
|
----+-------+------------
| Wire side
+------+
| 6LBR |
|(Root)|
+------+
o o o Wireless side
o o o o o o
o o o o o o o
o o o LLN o +---+
o o o o o |6LR|
o o o o o +---+
o o o o o o z
o o oo o o +---+
o |6LN|
+---+
]]></artwork></figure>
<t>
A leaf acting as a 6LN registers its unicast addresses to a RPL
router acting as a 6LR, using a layer-2 unicast NS message with an EARO as
specified in <xref target="RFC8505"/>.
The registration state is periodically renewed by the Registering Node,
before the lifetime indicated in the EARO expires. As for unicast IPv6
addresses, the 6LR uses an EDAR/EDAC exchange with the 6LBR to notify the
6LBR of the presence of the listeners.
</t><t>
This specification updates the EARO with a new two-bit field, the P-Field,
as detailed in <xref target="R8505E"/>.
The existing R flag that requests reachability for the registered address
gets new behavior.
With this extension the 6LNs can now subscribe to the anycast and multicast
addresses they listen to, using a new P-Field in the EARO to signal that the
registration is for a multicast address. Multiple 6LNs may subscribe
the same multicast address to the same 6LR. Note the use of the term
"subscribe": using the EARO registration mechanism, a node registers the
unicast addresses that it owns, but subscribes to the multicast addresses
that it listens to.
</t><t>
With this specification, the 6LNs can also subscribe the anycast addresses
they accept, using a new P-Field in the EARO to signal that the registration
is for an anycast address. As for multicast, multiple 6LNs may subscribe the
same anycast address to the same 6LR.
</t><t>
If the R flag is set in the subscription of one or more 6LNs for the same
address, the 6LR injects the anycast addresses and multicast addresses of a
scope larger than link-scope in RPL, based on the longest subscription
lifetime across the active subscriptions for the address.
</t><t>
In the RPL "Storing Mode of Operation with multicast support", the DAO
messages for the multicast address percolate along the RPL preferred parent
tree and mark a subtree that becomes the multicast tree for that multicast
address, with 6LNs that subscribed to the address as the leaves.
As prescribed in section 12 of <xref target="RFC6550"/>, the 6LR forwards a
multicast packet as an individual unicast MAC frame to each peer along the
multicast tree, except to the node it received the packet from.
</t><t>
In the new RPL "Non-Storing Mode of Operation with multicast support" that is
introduced here, the DAO messages announce the multicast addresses as Targets
though never as Transit. The multicast distribution is an ingress replication
whereby the Root encapsulates the multicast packets to all the 6LRs that are
transit for the multicast address, using the same source-routing header as
for unicast targets attached to the respective 6LRs.
</t><t>
LLN links are typically Direct MAC Broadcast (DMB)
(more in <xref target="I-D.ietf-6man-ipv6-over-wireless" />) with no
emulation to increase range (over multiple radio hops) or reliability.
In such links, broadcasting is unreliable and asynchronous transmissions force a listener
to remain awake, so asynchronous broadcasting is generally inefficient.
The expectation is thus that whenever possible, the 6LRs deliver the
multicast packets as individual unicast MAC
frames to each of the 6LNs that subscribed to the multicast address.
On the other hand, in a network where nodes do not sleep, asynchronous
broadcasting may still help recovering faster when state is lost.
</t><t>
With this specification, anycast addresses can be injected in RPL in both
Storing and Non-Storing modes. In Storing Mode the RPL router accepts DAO
from multiple children for the same anycast address, but only forwards a
packet to one of the children.
In Non-Storing Mode, the Root maintains the list of all the RPL nodes that
announced the anycast address as Target, but forwards a given packet to only
one of them.
</t>
<t>
Operationally speaking, deploying a new MOP means that one cannot update a live network. The network administrator must create a new instance
with MOP 5 and migrate nodes to that instance by allowing them to join it.
</t>
<t>For backward compatibility, this specification allows to build a single
DODAG signaled as MOP 1, that conveys anycast, unicast, and multicast packets
using the same source routing mechanism; more in <xref target="deploy"/>.
</t>
<t>
It is also possible to leverage this specification between the 6LN and the
6LR for the registration of unicast, anycast and multicast IPv6 addresses in
networks that are not necessarily LLNs, and/or where the routing protocol
between the 6LR and above is not necessarily RPL. In that case, the
distribution of packets between the 6LR and the 6LNs may effectively rely
on a broadcast or multicast support at the lower layer, e.g., using this
specification as a replacement to MLD in an Ethernet bridged domain and
still using either plain MAC-layer broadcast or snooping this protocol to
control the flooding. It may also rely on overlay services to optimize
the impact of Broadcast, Unknown, and Multicast (BUM) over a fabric, e.g.
registering with <xref target="I-D.thubert-bess-secure-evpn-mac-signaling"/>
and forwarding with <xref target="I-D.ietf-bess-evpn-optimized-ir"/>. </t>
<t>
For instance, it is possible to operate a RPL Instance in the new
"Non-Storing Mode of Operation with multicast support" (while possibly
signaling a MOP of 1) and use <xref target="RFC7731">"Multicast Protocol
for Low-Power and Lossy Networks (MPL)"</xref> for the multicast operation.
MPL floods the DODAG with the multicast messages independently of the RPL
DODAG topologies. Two variations are possible:
</t>
<ul>
<li>
In one possible variation, all the 6LNs set the R flag in the EARO for a
multicast target, upon which the 6LRs send a unicast DAO message to the
Root; the Root filters out the multicast messages for which there is no
listener and only floods when there is.
</li>
<li>
In a simpler variation, the 6LNs do not set the R flag and the Root floods
all the multicast packets over the whole DODAG. Using configuration, it is
also possible to control the behavior of the 6LR to ignore the R flag and
either always or never send the DAO message, and/or to control the Root and
specify which groups it should flood or not flood.
</li>
</ul>
<t>
Note that if the configuration instructs the 6LR not to send the DAO, then
MPL can really by used in conjunction with RPL Storing Mode as well.
</t>
</section> <!-- end section "Overview" -->
<!-- Target Address is not a multicast address. -->
<section anchor="tgt4861"><name>Updating RFC 4861</name>
<t>
Section 7.1 of <xref target="RFC4861"/> requires to silently discard NS and
NA packets when the Target Address is a multicast address. This specification
Amends <xref target="RFC4861"/> by allowing to advertise multicast and anycast
addresses in the Target Address field when the NS message is used for a
registration, per section 5.5 of <xref target="RFC8505"/>.
</t>
</section ><!-- Updating RFC 4861 -->
<section anchor="CIO"><name>Updating RFC 7400</name>
<t>
This specification Extends <xref target="RFC7400"> "6LoWPAN-GHC: Generic
Header Compression for IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs)"</xref> by defining a new capability bit for use in the
6CIO. <xref target="RFC7400"/> was already extended by <xref target="RFC8505"/> for use in IPv6 ND messages.
</t>
<t>
The new "Registration for xcast Address Supported" (X) flag indicates
to the 6LN that the 6LR accepts unicast, multicast, and anycast address
registrations as specified in this document and will ensure that packets
for the Registered Address will be routed to the 6LNs that registered with
the R flag set appropriately.
</t>
<t>
<xref target="fig6CIO"/> illustrates the X flag in its suggested position
(8, counting 0 to 15 in network order in the 16-bit array), to be confirmed by IANA.
</t>
<figure anchor="fig6CIO"><name>New Capability Bits in the 6CIO</name>
<artwork>
<![CDATA[
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 | Reserved |X|A|D|L|B|P|E|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t> New Option Field: </t>
<dl>
<dt>X</dt><dd> 1-bit flag: "Registration for Unicast, Multicast, and Anycast
Addresses Supported" </dd>
</dl>
</section> <!-- end section "Extending RFC 7400" -->
<section anchor="coex"><name>Updating RFC 6550</name>
<t>
This specification Amends <xref target="RFC6550"/> to mandate the use
of the ROVR field as the indication of the origin of a Target
advertisement in the RPL DAO messages, as specified as an option
in section 6.1 of <xref target="RFC9010"/>.
</t><t>
This specification Extends <xref target="RFC6550"/> with a new P-Field in the RPL Target Option.
</t><t>
The specification also Amends the behaviors of the Modes of Operation
MOP 1 and MOP 3, and Extends <xref target="RFC6550"/> with a new MOP 5.
</t>
<section anchor="mrovr"><name>Mandating the ROVR field</name>
<t>
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 recognised across multiple hops.
</t><t>
<xref target="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. <xref target="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.
</t><t>
This specification Extends <xref target="RFC6550"/> to require that,
for anycast and multicast advertisements, 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. But the freshness comparison cannot apply if the
origin is not determined (i.e., the origin did not support this specification).
</t><t>
<xref target="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.
<xref target="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.
</t><t>
The RPL router that merges multiple advertisements for the same anycast or
multicast addresses MUST use and advertise the longest remaining lifetime
across all the origins of the advertisements for that address.
When the lifetime expires, the router sends a no-path DAO (i.e., the lifetime
is 0) using the same value for ROVR value as for the previous advertisements,
that is either self or the single descendant that advertised the Target.
</t><t>
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 applies also to EDAR.
</t>
</section><!--Mandating the ROVR field-->
<section anchor="mop3"><name>Updating MOP 3</name>
<t>
RPL supports multicast operations in the "Storing Mode of Operation with
multicast support" (MOP 3) which provides source-independent multicast
routing in RPL, as prescribed in section 12 of <xref target="RFC6550"/>.
MOP 3 is a storing Mode of Operation. This operation builds a multicast
tree within the RPL DODAG for each multicast address. This specification
provides additional details for the MOP 3 operation.
</t> <t>
The expectation in MOP 3 is that the unicast traffic also follows the
Storing Mode of Operation. But this is rarely the case in LLN deployments
of RPL where the "Non-Storing Mode of Operation" (MOP 1) is the norm.
Though it is preferred to build separate RPL Instances, one in MOP 1 and one
in MOP 3, this specification allows hybrid use of the Storing Mode for multicast
and Non-Storing Mode for unicast in the same RPL Instance, as is elaborated in more detail in
<xref target="deploy"/>.
</t><t>
For anycast and multicast advertisements, including MOP 3, the ROVR field
is placed in the RPL Target Option as specified in <xref target=
"RFC9010"/> for both MOP 3 and MOP 5 as it is for unicast advertisements.
</t> <t>
Though it was implicit with <xref target="RFC6550"/>, this specification
clarifies that the freshness comparison based on the Path Sequence is not
used when the origin cannot be determined, which is the case there.
The comparison is to be used only between advertisements from the same
origin, which is either an individual subscriber, or a descendant that
merged multiple advertisements.
</t> <t>
A RPL router maintains a remaining Path Lifetime for each DAO that it
receives for a multicast target, and sends its own DAO for that target with
the longest remaining lifetime across its listening children. If the router
has only one descendant listening, it propagates the TID and ROVR as
received. Conversely, if the router merges multiple advertisements
(including possibly one for itself as a listener), the router uses
its own ROVR and TID values. This implies a possible transition of
ROVR and TID values when the number of listening children changes
from one to more or back to one, which should not be considered as an
error or a change of ownership by the parents above.
</t>
</section> <!-- end section "Updating MOP 3" -->
<section anchor="mop5"><name>New Non-Storing Multicast MOP</name>
<t>
This specification adds a "Non-Storing Mode of Operation with ingress
replication multicast support" (MOP to be assigned by IANA) whereby the
non-storing Mode DAO to
the Root may advertise a multicast address in the RPL Target Option (RTO),
whereas the Transit Information Option (TIO) cannot.
</t> <t>
In that mode, the RPL Root performs an ingress replication (IR) operation on
the multicast packets, meaning that it transmits one copy of each multicast
packet to each 6LR that is a transit for the multicast target, using the same
source routing header and encapsulation as it would for a unicast packet for
a RPL Unaware Leaf (RUL) attached to that 6LR.
</t> <t>
For the intermediate routers, the packet appears as any source routed unicast
packet. The difference shows only at the 6LR, that terminates the source
routed path and forwards the multicast packet to all 6LNs that registered
for the multicast address.
</t> <t>
For a packet that is generated by the Root, this means that the Root builds a
source routing header as shown in section 8.1.3 of <xref target="RFC9008"/>,
but for which the last and only the last address is multicast.
For a packet that is not generated by the Root, the Root encapsulates the
multicast packet as per section 8.2.4 of <xref target="RFC9008"/>. In that
case, the outer header is purely unicast, and the encapsulated packet is
purely multicast.
</t><t>
For anycast and multicast advertisements in NA (at the 6LR) and DAO (at the Root) messages, as discussed in <xref target="mop3"/>, the freshness
comparison based on the TID field is applied only between messages from the
same origin, as determined by the same value in the ROVR field.
</t><t>
The Root maintains a remaining Path Lifetime for each advertisement it receives,
and the 6LRs generate the DAO for multicast addresses with the longest
remaining lifetime across its registered 6LNs, using its own ROVR and TID when multiple 6LNs subscribed, or if this 6LR is one of the subscribers.
</t> <t>
For this new mode as well, this specification allows to enable the operation
in a MOP 1 brown field, more in <xref target="deploy"/>.
</t>
</section> <!-- end section "New Non-Storing Multicast MOP" -->
<section anchor="anic"><name>RPL Anycast Operation</name>
<t>
With multicast, the address has a recognizable format, and a multicast packet
is to be delivered to all the active subscribers.
In contrast, the format of an anycast address is not distinguishable
from that of unicast. A legacy node may issue a DAO message without setting
the P-Field to 2, the unicast behavior may apply to anycast traffic within
a portion of the network, but the packets will still be delivered.
That message will be undistinguishable from a unicast advertisement and the
anycast behavior in the dataplane can only happen if all the nodes that
advertise the same anycast address are synchronized with the same TID. That
way, the multiple paths can remain in the RPL DODAG.
</t> <t>
With the P-Field set to 2, this specification alleviates the issue of synchronizing
the TIDs and ROVR fields. As for multicast, the freshness comparison based
on the TID (in EARO) and the Path Sequence (in TIO) is ignored unless the
messages have the same origin, as inferred by the same ROVR in RTO and/or
EARO, and the latest value of the lifetime is retained for each origin.
</t>
<t>
A RPL router that propagates an advertisement from a single origin uses
the ROVR and Path Sequence from that origin, whereas a router that merges
multiple subscriptions uses its own ROVR and Path Sequence and the
longest lifetime over the different advertisements.
A target is routed as anycast by a parent (or the Root) that received at
least one DAO message for that target with the P-Field set to 2.
</t> <t>
As opposed to multicast, the anycast operation described therein applies to
both addresses and prefixes, and the P-Field can be set to 2 for both.
An external destination (address or prefix) that may be injected as a RPL
target from multiple border routers should be injected as anycast in RPL to
enable load balancing. A mobile target that is multihomed should in contrast
be advertised as unicast over the multiple interfaces to favor the TID
comparison and vs. the multipath load balancing.
</t> <t>
For either multicast and anycast, there can be multiple subscriptions from
multiple origins, each using a different value of the ROVR field that
identifies the individual subscription. The 6LR maintains a subscription
state per value of the ROVR per multicast or anycast address, but injects
the route into RPL only once for each address, and in the case of a
multicast address, only if its scope is larger than link-scope (3 or more).
Since the subscriptions are considered separate, the check on the TID that
acts as subscription sequence only applies to the subscription with the
same ROVR.
</t> <t>
Like the 6LR, a RPL router in Storing Mode propagates the merged advertisement to its parent(s) in DAO messages once and only once
for each address, but it retains a routing table entry for each of the
children that advertised the address.
</t> <t>
When forwarding multicast packets down the DODAG, the RPL router copies
all the children that advertised the address in their DAO messages. In
contrast, when forwarding anycast packets down the DODAG, the RPL router
MUST copy one and only one of the children that advertised the address in
their DAO messages, and forward to one parent if there is no such child.
</t>
</section> <!-- end section "RPL Anycast Operation" -->
<section anchor="newpf"><name>New Registered Address Type Indicator P-Field</name>
<t> The new Registered Address Type Indicator (RATInd) is created for use in RPL
Target Option, the EARO, and the header of EDAR messages.
The RATInd indicates whether an address is unicast, multicast, or anycast.
The new 2-bit P-Field is defined to transport the RATInd in different
protocols.
</t>
<t>
The P-Field can take the following values:
</t>
<table anchor="pVALS" ><name>P-Field Values</name>
<thead>
<tr><td>P-Field Value</td><td>Registered Address Type</td></tr>
</thead><tbody>
<tr><td>0</td><td>Registration for a Unicast Address or prefix</td></tr>
<tr><td>1</td><td>Registration for a Multicast Address</td></tr>
<tr><td>2</td><td>Registration for an Anycast Address</td></tr>
<tr><td>3</td><td>Reserved, MUST NOT be used by the sender.</td></tr>
</tbody>
</table> <!-- end table "P-Field values" -->
<t>
The intent for the value of 3 is a prefix registration (see <xref target="I-D.ietf-6lo-prefix-registration"/>, which is expected to be published soon after this specification. At the time of this writing, RPL already advertises prefixes, and treated unicast addresses as prefgixes with a length of 128, so it does not really need that new value. On the other hand, 6LoWPAN ND does not, and the value of 3 meaning prefix registration will not be processed adequately.
As a result:
</t>
<ul>
<li>
When the value of 3 is received in an RTO (see <xref target="newrtoflg"/>), this value MUST be ignored by the receiver, meaning, treated as a value of 0, but the message is processed normally (as per <xref target="RFC6550"/> and <xref target="RFC9010"/>).
</li>
<li>
In the case of an EARO (see <xref target="R8505E"/>) or an EDAR (see <xref target="R8505D"/>), the message MUST be dropped, and the receiving node MAY either reply with a status of 12 "Invalid Registration" or remain silent.
</li>
</ul>
</section><!-- New P-Field -->
<section anchor="newrtoflg"><name>New RPL Target Option P-Field</name>
<t>
<xref target="RFC6550"/> recognizes a multicast address by its format
(as specified in section 2.7 of <xref target="RFC4291"/>) and applies the
specified multicast operation if the address is recognized as multicast.
This specification updates <xref target="RFC6550"/> to add the 2-bit P-Field
(see <xref target="newpf"/>) to the RTO to indicate that the target address
is to be processed as unicast, multicast or anycast.
</t> <ul>
<li>An RTO that has the P-Field set to 0 is called a unicast RTO.</li>
<li>An RTO that has the P-Field set to 1 is called a multicast RTO.</li>
<li>An RTO that has the P-Field set to 2 is called an anycast RTO.</li>
</ul> <t>
The suggested position for the P-Field is 2 counting from 0 to
7 in network order as shown in <xref target="rto-fmt"/>, based on figure 4
of <xref target="RFC9010"/> which defines the flags in position 0 and 1:
</t>
<figure anchor="rto-fmt"><name>Format of the RPL Target Option</name>
<artwork align="center">
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 = 0x05 | Option Length |F|X| P |ROVRsz | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Prefix (Variable Length) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Registration Ownership Verifier (ROVR) ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t> New and updated Option Fields: </t>
<dl>
<dt>P:</dt><dd>2-bit field; see <xref target="newpf"/></dd>
</dl>
</section> <!-- end section "New RPL Target Option Flags" -->
</section> <!-- end section "Updating RFC 6550" -->
<section anchor="updating"><name>Updating RFC 8505</name>
<t>
This specification Extends <xref target="RFC8505"/> by adding the
concept of subscription for anycast and multicast addresses and
creating a new field called the P-Field in the EARO and the EDAR/EDAC
messages ti signal the type of registration.
</t>
<section anchor="R8505E"><name>Placing the New P-Field in the EARO</name>
<t>
Section 4.1 of <xref target="RFC8505"/> defines the EARO as an extension to
the ARO option defined in <xref target="RFC6775"/>.
This specification adds a new P-Field placed in the EARO flags that is set as
follows:
</t>
<ul>
<li>
The P-Field is set to 1 to signal that the
Registered Address is a multicast address. When the P-Field is 1 and the R flag
is set to 1 as well, the 6LR that
conforms to this specification joins the multicast stream, e.g., by
injecting the address in the RPL multicast support that is extended in this
specification for Non-Storing Mode.
</li>
<li>
The P-Field is set to 2 to signal that the Registered Address is
an anycast address. When the P-Field is 2 and the R flag is 1, the 6LR that
conforms to this specification injects the anycast address in the routing
protocol(s) that it participates to, e.g., in the RPL anycast support that
is introduced in this specification for both Storing and Non-Storing Modes.
</li>
</ul>
<t>
<xref target="EARO"/> illustrates the P-Field in its suggested
positions (2, counting 0 to 7 in network order in the
8-bit array), to be confirmed by IANA.
</t>
<figure anchor="EARO"><name>EARO Option Format</name>
<artwork align="center">
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 | Status | Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Rsv| P | I |R|T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Registration Ownership Verifier ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure><!-- end figure "EARO Option Format" -->
<t> New and updated Option Fields: </t>
<dl>
<dt>Rsv:</dt><dd> 2-bit field; reserved, MUST be set to 0 and ignored by the receiver</dd>
<dt>P:</dt><dd>2-bit P-Field; see <xref target="newpf"/></dd>
</dl>
</section> <!-- end section "Placing the New P-Field in the EARO" -->
<section anchor="R8505D"><name>Placing the New P-Field in the EDAR Message</name>
<t>
Section 4 of <xref target="RFC6775"/> provides the same format for DAR and
DAC messages but the status field is only used in DAC messages and has to be
set to zero in DAR messages. <xref target="RFC8505"/> extends the DAC message
as an EDAC but does not change the status field in the EDAR.
</t>
<t>
This specification repurposes the status field in the EDAR as a Flags field.
It adds a new P-Field to the EDAR flags field to match the P-Field in the
EARO and signal the new types of registration. The EDAC message is not
modified.
</t>
<t>
<xref target="EDAR"/> illustrates the P-Field in its suggested position