-
Notifications
You must be signed in to change notification settings - Fork 9
/
draft-ietf-lpwan-schc-over-lorawan.xml
1318 lines (1024 loc) · 62.7 KB
/
draft-ietf-lpwan-schc-over-lorawan.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"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.24 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<rfc ipr="trust200902" docName="draft-ietf-lpwan-schc-over-lorawan-14" category="std">
<front>
<title abbrev="SCHC-over-LoRaWAN">Static Context Header Compression (SCHC) over LoRaWAN</title>
<author initials="O." surname="Gimenez" fullname="Olivier Gimenez" role="editor">
<organization>Semtech</organization>
<address>
<postal>
<street>14 Chemin des Clos</street>
<city>Meylan</city>
<country>France</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author initials="I." surname="Petrov" fullname="Ivaylo Petrov" role="editor">
<organization>Acklio</organization>
<address>
<postal>
<street>1137A Avenue des Champs Blancs</street>
<city>35510 Cesson-Sevigne Cedex</city>
<country>France</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date year="2021" month="February" day="01"/>
<workgroup>lpwan Working Group</workgroup>
<abstract>
<t>The Static Context Header Compression (SCHC) specification describes generic
header compression and fragmentation techniques for Low Power Wide Area
Networks (LPWAN) technologies. SCHC is a generic mechanism designed for great
flexibility so that it can be adapted for any of the LPWAN technologies.</t>
<t>This document specifies a profile of RFC8724 to use SCHC in LoRaWAN® networks,
and provides elements such as efficient parameterization and modes of
operation.</t>
</abstract>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t>SCHC specification <xref target="RFC8724"></xref> describes
generic header compression and fragmentation techniques that can be used on all
Low Power Wide Area Networks (LPWAN) technologies defined in
<xref target="RFC8376"/>. Even though those technologies share a great
number of common features like star-oriented topologies, network architecture,
devices with mostly quite predictable communications, etc; they do have some
slight differences with respect to payload sizes, reactiveness, etc.</t>
<t>SCHC provides a generic framework that enables those devices to communicate on
IP networks. However, for efficient performance, some parameters
and modes of operation need to be set appropriately for each of the LPWAN
technologies.</t>
<t>This document describes the parameters and modes of operation when
SCHC is used over LoRaWAN networks. LoRaWAN protocol is specified by the
LoRa Alliance® in <xref target="lora-alliance-spec"/></t>
</section>
<section anchor="terminology" title="Terminology">
<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>This section defines the terminology and acronyms used in this document. For
all other definitions, please look up the SCHC specification
<xref target="RFC8724"></xref>.</t>
<t><list style="symbols">
<t>DevEUI: Device Extended Unique Identifier, an IEEE EUI-64 identifier
used to identify the device during the
procedure while joining the network (Join Procedure). It is assigned by the
manufacturer or the device owner and provisioned on the Network Gateway.</t>
<t>DevAddr: a 32-bit non-unique identifier assigned to a device either: <list style="symbols">
<t>Statically: by the device manufacturer in <spanx style="emph">Activation by Personalization</spanx>
mode.</t>
<t>Dynamically: after a Join Procedure by the Network Gateway in <spanx style="emph">Over The
Air Activation</spanx> mode.</t>
</list></t>
<t>Downlink: LoRaWAN term for a frame transmitted by the network and
received by the device.</t>
<t>EUI: Extended Unique Identifier</t>
<t>LoRaWAN: LoRaWAN is a wireless technology based on Industrial,
Scientific, and Medical (ISM) radio bands that is used for long-range,
low-power, low-data-rate applications developed by the LoRa Alliance, a
membership consortium: <eref target="https://www.lora-alliance.org">https://www.lora-alliance.org</eref>.</t>
<t>FRMPayload: Application data in a LoRaWAN frame.</t>
<t>MSB: Most Significant Byte</t>
<t>OUI: Organisation Unique Identifier. IEEE assigned prefix for EUI.</t>
<t>RCS: Reassembly Check Sequence. Used to verify the integrity of the
fragmentation-reassembly process.</t>
<t>RX: Device’s reception window.</t>
<t>RX1/RX2: LoRaWAN class A devices open two RX windows following an
uplink, called RX1 and RX2.</t>
<t>SCHC gateway: The LoRaWAN Application Server that manages translation
between IPv6 network and the Network Gateway (LoRaWAN Network
Server).</t>
<t>Tile: Piece of a fragmented packet as described in <xref target="RFC8724"></xref> section 8.2.2.1</t>
<t>Uplink: LoRaWAN term for a frame transmitted by the device and received
by the network.</t>
</list></t>
</section>
<section anchor="static-context-header-compression-overview" title="Static Context Header Compression Overview">
<t>This section contains a short overview of SCHC. For a detailed description,
refer to the full specification <xref target="RFC8724"></xref>.</t>
<t>It defines:</t>
<t><list style="numbers">
<t>Compression mechanisms to avoid transporting information known by both
sender and receiver over the air. Known information is part of the
“context”. This component is called SCHC Compressor/Decompressor (SCHC C/D).</t>
<t>Fragmentation mechanisms to allow SCHC Packet transportation on small, and
potentially variable, MTU. This component is called SCHC Fragmentation/Reassembly
(SCHC F/R).</t>
</list></t>
<t>Context exchange or pre-provisioning is out of scope of this document.</t>
<figure title="Architecture" anchor="Fig-archi"><artwork><![CDATA[
Device App
+----------------+ +----+ +----+ +----+
| App1 App2 App3 | |App1| |App2| |App3|
| | | | | | | |
| UDP | |UDP | |UDP | |UDP |
| IPv6 | |IPv6| |IPv6| |IPv6|
| | | | | | | |
|SCHC C/D and F/R| | | | | | |
+--------+-------+ +----+ +----+ +----+
| +---+ +----+ +----+ +----+ . . .
+~ |RGW| === |NGW | == |SCHC| == |SCHC|...... Internet ....
+---+ +----+ |F/R | |C/D |
+----+ +----+
|<- - - - LoRaWAN - - ->|
]]></artwork></figure>
<t><xref target="Fig-archi"/> represents the architecture for compression/decompression, it is
based on <xref target="RFC8376"/> terminology. The device is sending applications flows
using IPv6 or IPv6/UDP protocols. These flows might be compressed by a Static
Context Header Compression Compressor/Decompressor (SCHC C/D) to reduce headers
size and fragmented by the SCHC Fragmentation/Reassembly (SCHC F/R).
The resulting information is sent on a layer two
(L2) frame to an LPWAN Radio Gateway (RGW) that forwards the frame to a Network
Gateway (NGW). The NGW sends the data to a SCHC F/R for reassembly, if
required, then to SCHC C/D for decompression. The SCHC C/D shares the same rules with the
device. The SCHC C/D and F/R can be located on the Network Gateway (NGW) or in
another place as long as a communication is established between the NGW and the SCHC
F/R, then SCHC F/R and C/D. The SCHC C/D and F/R in the device and the SCHC gateway MUST
share the same set of rules. After decompression, the packet can be sent on the Internet to
one or several LPWAN Application Servers (App).</t>
<t>The SCHC C/D and F/R process is bidirectional, so the same principles can
be applied to the other direction.</t>
<t>In a LoRaWAN network, the RGW is called a Gateway, the NGW is Network Server,
and the SCHC C/D and F/R are an Application Server. It can be provided by
the Network Gateway or any third party software. <xref target="Fig-archi"/> can be mapped in
LoRaWAN terminology to:</t>
<figure title="SCHC Architecture mapped to LoRaWAN" anchor="Fig-archi-lorawan"><artwork><![CDATA[
End Device App
+--------------+ +----+ +----+ +----+
|App1 App2 App3| |App1| |App2| |App3|
| | | | | | | |
| UDP | |UDP | |UDP | |UDP |
| IPv6 | |IPv6| |IPv6| |IPv6|
| | | | | | | |
|SCHC C/D & F/R| | | | | | |
+-------+------+ +----+ +----+ +----+
| +-------+ +-------+ +-----------+ . . .
+~ |Gateway| === |Network| == |Application|..... Internet ....
+-------+ |server | |server |
+-------+ | F/R - C/D |
+-----------+
|<- - - - - LoRaWAN - - - ->|
]]></artwork></figure>
</section>
<section anchor="lorawan-architecture" title="LoRaWAN Architecture">
<t>An overview of LoRaWAN <xref target="lora-alliance-spec"/> protocol and architecture is
described in <xref target="RFC8376"/>. The mapping between the LPWAN
architecture entities as described in <xref target="RFC8724"></xref>
and the ones in <xref target="lora-alliance-spec"/> is as follows:</t>
<t>o Devices are LoRaWAN End Devices (e.g. sensors,
actuators, etc.). There can be a very high density of devices per
radio gateway (LoRaWAN gateway). This entity maps to the LoRaWAN end-device.</t>
<t>o The Radio Gateway (RGW), which is the endpoint of the constrained
link. This entity maps to the LoRaWAN Gateway.</t>
<t>o The Network Gateway (NGW) is the interconnection node between the
Radio Gateway and the SCHC gateway (LoRaWAN Application server). This
entity maps to the LoRaWAN Network Server.</t>
<t>o SCHC C/D and F/R are handled by LoRaWAN Application Server; ie the LoRaWAN
application server will do the SCHC C/D and F/R.</t>
<t>o The LPWAN-AAA Server is the LoRaWAN Join Server. Its role is to manage and
deliver security keys in a secure way, so that the devices root key is never exposed.</t>
<figure title="LPWAN Architecture" anchor="Fig-LPWANarchi"><artwork><![CDATA[
(LPWAN-AAA Server)
() () () | +------+
() () () () / \ +---------+ | Join |
() () () () () / \======| ^ |===|Server| +-----------+
() () () | | <--|--> | +------+ |Application|
() () () () / \==========| v |=============| Server |
() () () / \ +---------+ +-----------+
End-devices Gateways Network Server (SCHC C/D and F/R)
(devices) (RGW) (NGW)
]]></artwork></figure>
<t><spanx style="emph">Note</spanx>: <xref target="Fig-LPWANarchi"/> terms are from LoRaWAN, with <xref target="RFC8376"/> terminology in brackets.</t>
<t>SCHC Compressor/Decompressor (SCHC C/D) and SCHC Fragmentation/Reassembly (SCHC F/R)
are performed on the LoRaWAN end-device and the Application Server (called
SCHC gateway). While the point-to-point link between the device and the
Application Server constitutes a single IP hop, the ultimate end-point of the
IP communication may be an Internet node beyond the Application Server.
In other words, the LoRaWAN Application Server (SCHC gateway) acts as the
first hop IP router for the device. The Application Server and Network
Server may be co-located, which effectively turns the Network/Application
Server into the first hop IP router.</t>
<section anchor="device-classes-a-b-c-and-interactions" title="Device classes (A, B, C) and interactions">
<t>The LoRaWAN MAC layer supports 3 classes of devices named A, B and C. All
devices implement the Class A, some devices may implement Class B or
Class C. Class B and Class C are mutually exclusive.</t>
<t><list style="symbols">
<t>Class A: The Class A is the simplest class of devices. The device is
allowed to transmit at any time, randomly selecting a communication channel.
The Network Gateway may reply with a downlink in one of the 2 receive windows
immediately following the uplinks. Therefore, the Network Gateway cannot initiate a
downlink, it has to wait for the next uplink from the device to get a
downlink opportunity. The Class A is the lowest power consumption class.</t>
<t>Class B: Class B devices implement all the functionalities of Class A
devices, but also schedule periodic listen windows. Therefore, opposed to the
Class A devices, Class B devices can receive downlinks that are initiated by the
Network Gateway and not following an uplink. There is a trade-off between the
periodicity of those scheduled Class B listen windows and the power
consumption of the device: if the periodicity is high downlinks from the NGW
will be sent faster, but the device wakes up more often: it will have higher
power consumption.</t>
<t>Class C: Class C devices implement all the functionalities of Class A
devices, but keep their receiver open whenever they are not transmitting.
Class C devices can receive downlinks at any time at the expense of a higher
power consumption. Battery-powered devices can only operate in Class C for a
limited amount of time (for example for a firmware upgrade over-the-air).
Most of the Class C devices are grid powered (for example Smart Plugs).</t>
</list></t>
</section>
<section anchor="device-addressing" title="Device addressing">
<t>LoRaWAN end-devices use a 32-bit network address (devAddr) to communicate with
the Network Gateway over-the-air, this address might not be unique in a LoRaWAN
network. Devices using the same devAddr are distinguished by the Network
Gateway based on the cryptographic signature appended to every LoRaWAN frame.</t>
<t>To communicate with the SCHC gateway, the Network Gateway MUST identify the
devices by a unique 64-bit device identifier called the DevEUI.</t>
<t>The DevEUI is assigned to the device during the manufacturing process by the
device’s manufacturer. It is built like an Ethernet MAC address by
concatenating the manufacturer’s IEEE OUI field with a vendor unique number.
e.g.: 24-bit OUI is concatenated with a 40-bit serial number.
The Network Gateway translates the devAddr into a DevEUI in the uplink
direction and reciprocally on the downlink direction.</t>
<figure title="LoRaWAN addresses" anchor="Fig-LoRaWANaddresses"><artwork><![CDATA[
+--------+ +---------+ +---------+ +----------+
| Device | <=====> | Network | <====> | SCHC | <======> | Internet |
| | devAddr | Gateway | DevEUI | Gateway | IPv6/UDP | |
+--------+ +---------+ +---------+ +----------+
]]></artwork></figure>
</section>
<section anchor="general-frame-types" title="General Frame Types">
<t>LoRaWAN implements the possibility to send confirmed or unconfirmed frames:</t>
<t><list style="symbols">
<t>Confirmed frame:
The sender asks the receiver to acknowledge the frame.</t>
<t>Unconfirmed frame:
The sender does not ask the receiver to acknowledge the frame.</t>
</list></t>
<t>As SCHC defines its own acknowledgment mechanisms, SCHC does not require
the use of LoRaWAN Confirmed frames (MType=0b100 as per
<xref target="lora-alliance-spec"/>)</t>
</section>
<section anchor="lorawan-mac-frames" title="LoRaWAN MAC Frames">
<t>In addition to regular data frames, LoRaWAN implements JoinRequest and JoinAccept
frame types, which are used by a device to join a network:</t>
<t><list style="symbols">
<t>JoinRequest:
This frame is used by a device to join a network. It contains the device’s
unique identifier DevEUI and a random nonce that will be used for session key
derivation.</t>
<t>JoinAccept:
To on-board a device, the Network Gateway responds to the JoinRequest
issued by a device with a JoinAccept frame. That frame is
encrypted with the device’s AppKey and contains (amongst other fields)
the network’s major settings and a random nonce used to derive the session
keys.</t>
<t>Data:
MAC and application data. Application data are protected with AES-128
encryption. MAC related data are AES-128 encrypted with another key.</t>
</list></t>
</section>
<section anchor="lorawan-fport" title="LoRaWAN FPort">
<t>The LoRaWAN MAC layer features a frame port field in all frames. This field
(FPort) is 8 bits long and the values from 1 to 223 can be used. It allows
LoRaWAN networks and applications to identify data.</t>
</section>
<section anchor="lorawan-empty-frame" title="LoRaWAN empty frame">
<t>A LoRaWAN empty frame is a LoRaWAN frame without FPort (cf <xref target="lorawan-schc-payload"/>)
and FRMPayload.</t>
</section>
<section anchor="unicast-and-multicast-technology" title="Unicast and multicast technology">
<t>LoRaWAN technology supports unicast downlinks, but also multicast: a packet
sent over LoRaWAN radio link can be received by several devices. It is
useful to address many devices with same content, either a large binary
file (firmware upgrade), or same command (e.g: lighting control).
As IPv6 is also a multicast technology this feature can be used to address a
group of devices.</t>
<t><spanx style="emph">Note 1</spanx>: IPv6 multicast addresses must be defined as per <xref target="RFC4291"></xref>. LoRaWAN
multicast group definition in a Network Gateway and the relation between those
groups and IPv6 groupID are out of scope of this document.</t>
<t><spanx style="emph">Note 2</spanx>: LoRa Alliance defined <xref target="lora-alliance-remote-multicast-set"/> as
the RECOMMENDED way to setup multicast groups on devices and create a synchronized
reception window.</t>
</section>
</section>
<section anchor="schc-over-lorawan" title="SCHC-over-LoRaWAN">
<section anchor="lorawan-schc-payload" title="LoRaWAN FPort and RuleID">
<t>The FPort field is part of the SCHC Message, as shown in
<xref target="Fig-lorawan-schc-payload"/>. The SCHC C/D and the SCHC F/R SHALL concatenate
the FPort field with the LoRaWAN payload to recompose the SCHC Message.</t>
<figure title="SCHC Message in LoRaWAN" anchor="Fig-lorawan-schc-payload"><artwork><![CDATA[
| FPort | LoRaWAN payload |
+ ------------------------ +
| SCHC Message |
]]></artwork></figure>
<t>Note: SCHC Message is any datagram sent by SCHC C/D or F/R layers.</t>
<t>A fragmented datagram with application payload transferred from device to
Network Gateway, is called an uplink fragmented datagram. It uses an FPort for data uplink
and its associated SCHC control downlinks, named FPortUp in this document. The
other way, a fragmented datagram with application payload transferred from
Network Gateway to device, is called downlink fragmented datagram. It uses another
FPort for data downlink and its associated SCHC control uplinks, named FPortDown
in this document.</t>
<t>All RuleID can use arbitrary values inside the FPort range allowed by LoRaWAN
specification and MUST be shared by the device and SCHC gateway prior to
the communication with the selected rule.
The uplink and downlink fragmentation FPorts MUST be different.</t>
</section>
<section anchor="rule-id-management" title="Rule ID management">
<t>RuleID MUST be 8 bits, encoded in the LoRaWAN FPort as described in
<xref target="lorawan-schc-payload"/>. LoRaWAN supports up to 223 application FPorts in
the range [1;223] as defined in section 4.3.2 of <xref target="lora-alliance-spec"/>, it implies
that RuleID MSB SHOULD be inside this range. An application can send non SCHC
traffic by using FPort values different from the ones used for SCHC.</t>
<t>In order to improve interoperability, RECOMMENDED fragmentation RuleID values are:</t>
<t><list style="symbols">
<t>RuleID = 20 (8-bit) for uplink fragmentation, named FPortUp.</t>
<t>RuleID = 21 (8-bit) for downlink fragmentation, named FPortDown.</t>
<t>RuleID = 22 (8-bit) for which SCHC compression was not possible (i.e., no matching
compression Rule was found), as described in <xref target="RFC8724"/> section 6.</t>
</list></t>
<t>FPortUp value MUST be different from FPortDown.
The remaining RuleIDs are available for compression. RuleIDs are shared between
uplink and downlink sessions. A RuleID not in the set(s) of FPortUp or FPortDown
means that the fragmentation is not used, thus, on reception, the SCHC Message
MUST be sent to the SCHC C/D layer.</t>
<t>The only uplink frames using the FPortDown port are the fragmentation SCHC
control messages of a downlink fragmented datagram (for example, SCHC ACKs).
Similarly, the only downlink frames using the FPortUp port are the
fragmentation SCHC control messages of an uplink fragmented datagram.</t>
<t>An application can have multiple fragmented datagrams between a device and one
or several SCHC gateways. A set of FPort values is REQUIRED for each SCHC gateway
instance the device is required to communicate with. The application can use
additional uplinks or downlink fragmented parameters but SHALL implement at
least the parameters defined in this document.</t>
<t>The mechanism for context distribution across devices and gateways is
outside the scope of this document.</t>
</section>
<section anchor="IID" title="Interface IDentifier (IID) computation">
<t>In order to mitigate the risks described in <xref target="RFC8064"></xref> and <xref target="RFC8065"></xref>,
implementation MUST implement the following algorithm and SHOULD use it.</t>
<t><list style="numbers">
<t>key = LoRaWAN AppSKey</t>
<t>cmac = aes128_cmac(key, DevEUI)</t>
<t>IID = cmac[0..7]</t>
</list></t>
<t>aes128_cmac algorithm is described in <xref target="RFC4493"></xref>. It has been chosen as it is
already used by devices for LoRaWAN protocol.</t>
<t>As AppSKey is renewed each time a device joins or rejoins a LoRaWAN network,
the IID will change over time; this mitigates privacy, location tracking and
correlation over time risks. Join periodicity is defined at the application
level.</t>
<t>Address scan risk is mitigated thanks to AES-128, which provides enough entropy
bits of the IID.</t>
<t>Using this algorithm will also ensure that there is no correlation between the
hardware identifier (IEEE-64 DevEUI) and the IID, so an attacker cannot use
manufacturer OUI to target devices.</t>
<t>Example with:</t>
<t><list style="symbols">
<t>DevEUI: 0x1122334455667788</t>
<t>appSKey: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB</t>
</list></t>
<figure title="Example of IID computation." anchor="Fig-iid-computation-example"><artwork><![CDATA[
1. key: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB
2. cmac: 0xBA59F4B196C6C3432D9383C145AD412A
3. IID: 0xBA59F4B196C6C343
]]></artwork></figure>
<t>There is a small probability of IID collision in a LoRaWAN network. If this occurs,
the IID can be changed by rekeying the device at L2 level (ie: trigger a LoRaWAN
join).
The way the device is rekeyed is out of scope of this document and left to the
implementation.</t>
<t>Note: Implementation also using another IID source MUST ensure that the
same IID is shared between the device and the SCHC gateway in the
compression and decompression of the IPv6 address of the device.</t>
</section>
<section anchor="padding" title="Padding">
<t>All padding bits MUST be 0.</t>
</section>
<section anchor="Decomp" title="Decompression">
<t>SCHC C/D MUST concatenate FPort and LoRaWAN payload to retrieve the SCHC Packet
as per <xref target="lorawan-schc-payload"/>.</t>
<t>RuleIDs matching FPortUp and FPortDown are reserved for SCHC Fragmentation.</t>
</section>
<section anchor="Frag" title="Fragmentation">
<t>The L2 Word Size used by LoRaWAN is 1 byte (8 bits).
The SCHC fragmentation over LoRaWAN uses the ACK-on-Error mode for uplink
fragmentation and Ack-Always mode for downlink fragmentation. A LoRaWAN
device cannot support simultaneous interleaved fragmented datagrams in
the same direction (uplink or downlink).</t>
<t>The fragmentation parameters are different for uplink and downlink
fragmented datagrams and are successively described in the next sections.</t>
<section anchor="DTag" title="DTag">
<t><xref target="RFC8724"></xref> section 8.2.4 describes the possibility to interleave several
fragmented SCHC datagrams for the same RuleID. This is not used in SCHC over
LoRaWAN profile. A device cannot interleave several fragmented SCHC datagrams
on the same FPort. This field is not used and its size is 0.</t>
<t>Note: The device can still have several parallel fragmented datagrams with
more than one SCHC gateway thanks to distinct sets of FPorts, cf <xref target="rule-id-management"/>.</t>
</section>
<section anchor="uplink-fragmentation-from-device-to-schc-gateway" title="Uplink fragmentation: From device to SCHC gateway">
<t>In this case, the device is the fragment transmitter, and the SCHC gateway
the fragment receiver. A single fragmentation rule is defined.
SCHC F/R MUST concatenate FPort and LoRaWAN payload to retrieve the SCHC
Packet, as per <xref target="lorawan-schc-payload"/>.</t>
<t><list style="symbols">
<t>SCHC fragmentation reliability mode: <spanx style="verb">ACK-on-Error</spanx>.</t>
<t>SCHC header size is two bytes (the FPort byte + 1 additional byte).</t>
<t>RuleID: 8 bits stored in LoRaWAN FPort. cf <xref target="rule-id-management"/></t>
<t>DTag: Size T=0 bit, not used. cf <xref target="DTag"/></t>
<t>Window index: 4 windows are used, encoded on M = 2 bits</t>
<t>FCN: The FCN field is encoded on N = 6 bits, so WINDOW_SIZE = 63 tiles
are allowed in a window.</t>
<t>Last tile: it can be carried in a Regular SCHC Fragment, alone in an All-1 SCHC
Fragment or with any of these two methods. Implementation must ensure that:
<list style="symbols">
<t>The sender MUST ascertain that the receiver will not receive
the last tile through both a Regular SCHC Fragment and an All-1 SCHC
Fragment during the same session.</t>
<t>If the last tile is in All-1 SCHC message: current L2 MTU MUST be big enough to fit
the All-1 header and the last tile.</t>
</list></t>
<t>Penultimate tile MUST be equal to the regular size.</t>
<t>RCS: Use recommended calculation algorithm in <xref target="RFC8724"></xref> (§8.2.3. Integrity Checking).</t>
<t>Tile: size is 10 bytes.</t>
<t>Retransmission timer: Set by the implementation depending on the application
requirements. The default RECOMMENDED duration of this timer is 12 hours;
this value is mainly driven by application requirements and MAY be
changed by the application.</t>
<t>Inactivity timer: The SCHC gateway implements an “inactivity timer”. The
default RECOMMENDED duration of this timer is 12 hours; this value is mainly
driven by application requirements and MAY be changed by the application.</t>
<t>MAX_ACK_REQUESTS: 8.
With this set of parameters, the SCHC fragment header is 16 bits,
including FPort; payload overhead will be 8 bits as FPort is already a part of
LoRaWAN payload. MTU is: <spanx style="emph">4 windows * 63 tiles * 10 bytes per tile = 2520 bytes</spanx></t>
</list></t>
<t>In addition to the per-rule context parameters specified in <xref target="RFC8724"></xref>,
for uplink rules, an additional context parameter is added: whether or
not to ack after each window.<vspace />
For battery powered devices, it is RECOMMENDED to use the ACK mechanism at the
end of each window instead of waiting until the end of all windows:</t>
<t><list style="symbols">
<t>The SCHC receiver SHOULD send a SCHC ACK after every window even if there is no
missing tile.</t>
<t>The SCHC sender SHOULD wait for the SCHC ACK from the SCHC receiver before sending
tiles from the next window. If the SCHC ACK is not received, it SHOULD send a SCHC
ACK REQ up to MAX_ACK_REQUESTS times, as described previously.</t>
</list></t>
<t>This will avoid useless uplinks if the device has lost network coverage.</t>
<t>For non-battery powered devices, the SCHC receiver MAY also choose to send a SCHC
ACK only at the end of all windows. This will reduce downlink load on the LoRaWAN
network, by reducing the number of downlinks.</t>
<t>SCHC implementations MUST be compatible with both behaviors, and this selection is
part of the rule context.</t>
<section anchor="regular-fragments" title="Regular fragments">
<figure title="All fragments except the last one. SCHC header size is 16 bits, including LoRaWAN FPort." anchor="Fig-fragmentation-header-long-all0"><artwork><![CDATA[
| FPort | LoRaWAN payload |
+ ------ + ------------------------- +
| RuleID | W | FCN | Payload |
+ ------ + ------ + ------ + ------- +
| 8 bits | 2 bits | 6 bits | |
]]></artwork></figure>
</section>
<section anchor="last-fragment-all-1" title="Last fragment (All-1)">
<figure title="All-1 SCHC Message: the last fragment without last tile." anchor="Fig-fragmentation-header-all1-no-tile"><artwork><![CDATA[
| FPort | LoRaWAN payload |
+ ------ + ---------------------------- +
| RuleID | W | FCN=All-1 | RCS |
+ ------ + ------ + --------- + ------- +
| 8 bits | 2 bits | 6 bits | 32 bits |
]]></artwork></figure>
<figure title="All-1 SCHC Message: the last fragment with last tile." anchor="Fig-fragmentation-header-all1-last-tile"><artwork><![CDATA[
| FPort | LoRaWAN payload |
+ ------ + ---------------------------------------------------------- +
| RuleID | W | FCN=All-1 | RCS | Last tile | Opt. padding |
+ ------ + ------ + --------- + ------- + ------------ + ------------ +
| 8 bits | 2 bits | 6 bits | 32 bits | 1 to 80 bits | 0 to 7 bits |
]]></artwork></figure>
</section>
<section anchor="schc-ack" title="SCHC ACK">
<figure title="SCHC ACK format, correct RCS check." anchor="Fig-frag-header-long-schc-ack-rcs-ok"><artwork><![CDATA[
| FPort | LoRaWAN payload |
+ ------ + --------------------------+
| RuleID | W | C = 1 | padding |
| | | | (b'00000) |
+ ------ + ----- + ----- + --------- +
| 8 bits | 2 bit | 1 bit | 5 bits |
]]></artwork></figure>
<figure title="SCHC ACK format, failed RCS check." anchor="Fig-frag-header-long-schc-ack-rcs-fail"><artwork><![CDATA[
| FPort | LoRaWAN payload |
+ ------ + --------------------------------- + ---------------- +
| RuleID | W | C = 0 | Compressed bitmap | Optional padding |
| | | | (C = 0) | (b'0...0) |
+ ------ + ----- + ----- + ----------------- + ---------------- +
| 8 bits | 2 bit | 1 bit | 5 to 63 bits | 0, 6 or 7 bits |
]]></artwork></figure>
<t>Note: Because of the bitmap compression mechanism and L2 byte alignment, only
the following discrete values are possible for the compressed bitmap size: 5, 13, 21, 29, 37, 45, 53, 61, 62 and 63.
Bitmaps of 63 bits will require 6 bits of padding.</t>
</section>
<section anchor="receiver-abort" title="Receiver-Abort">
<figure title="Receiver-Abort format." anchor="Fig-fragmentation-receiver-abort"><artwork><![CDATA[
| FPort | LoRaWAN payload |
+ ------ + -------------------------------------------- +
| RuleID | W = b'11 | C = 1 | b'11111 | 0xFF (all 1's) |
+ ------ + -------- + ------+-------- + ----------------+
| 8 bits | 2 bits | 1 bit | 5 bits | 8 bits |
next L2 Word boundary ->| <-- L2 Word --> |
]]></artwork></figure>
</section>
<section anchor="schc-acknowledge-request" title="SCHC acknowledge request">
<figure title="SCHC ACK REQ format." anchor="Fig-fragmentation-schc-ack-req"><artwork><![CDATA[
| FPort | LoRaWAN payload |
+------- +------------------------- +
| RuleID | W | FCN = b'000000 |
+ ------ + ------ + --------------- +
| 8 bits | 2 bits | 6 bits |
]]></artwork></figure>
</section>
</section>
<section anchor="downlink-fragmentation-from-schc-gateway-to-device" title="Downlink fragmentation: From SCHC gateway to device">
<t>In this case, the device is the fragmentation receiver, and the SCHC gateway the
fragmentation transmitter. The following fields are common to all devices.
SCHC F/R MUST concatenate FPort and LoRaWAN payload to retrieve the SCHC
Packet as described in <xref target="lorawan-schc-payload"/>.</t>
<t><list style="symbols">
<t>SCHC fragmentation reliability mode:
<list style="symbols">
<t>Unicast downlinks: ACK-Always.</t>
<t>Multicast downlinks: No-ACK, reliability has to be ensured by the upper
layer. This feature is OPTIONAL and may not be implemented by SCHC gateway.</t>
</list></t>
<t>RuleID: 8 bits stored in LoRaWAN FPort. cf <xref target="rule-id-management"/></t>
<t>DTag: Size T=0 bit, not used. cf <xref target="DTag"/></t>
<t>FCN: The FCN field is encoded on N=1 bit, so WINDOW_SIZE = 1 tile.</t>
<t>RCS: Use recommended calculation algorithm in <xref target="RFC8724"></xref> (§8.2.3. Integrity Checking).</t>
<t>Inactivity timer: The default RECOMMENDED duration of this timer is 12 hours;
this value is mainly driven by application requirements and MAY be changed by
the application.</t>
</list></t>
<t>The following parameters apply to ACK-Always (Unicast) only:</t>
<t><list style="symbols">
<t>Retransmission timer: See <xref target="downlink-retransmission-timer"/>.</t>
<t>MAX_ACK_REQUESTS: 8.</t>
<t>Window index (unicast only): encoded on M=1 bit, as per <xref target="RFC8724"></xref>.</t>
</list></t>
<t>As only 1 tile is used, its size can change for each downlink, and will be
the currently available MTU.</t>
<t>Class A devices can only receive during an RX slot, following the transmission of an
uplink. Therefore the SCHC gateway cannot initiate communication (e.g., start a new SCHC
session). In order to create a downlink opportunity it is RECOMMENDED for
Class A devices to send an uplink every 24 hours when no SCHC session is
started, this is application specific and can be disabled. The RECOMMENDED uplink
is a LoRaWAN empty frame as defined <xref target="lorawan-empty-frame"/>.
As this uplink is to open an RX window, any LoRaWAN uplink frame from the device
MAY reset this counter.</t>
<t><spanx style="emph">Note</spanx>: The Fpending bit included in LoRaWAN protocol SHOULD NOT be used for
SCHC-over-LoRaWAN protocol. It might be set by the Network Gateway for other
purposes but not SCHC needs.</t>
<section anchor="regular-fragments-1" title="Regular fragments">
<figure title="All fragments but the last one. Header size 10 bits, including LoRaWAN FPort." anchor="Fig-fragmentation-downlink-header-all0"><artwork><![CDATA[
| FPort | LoRaWAN payload |
+ ------ + ------------------------------------ +
| RuleID | W | FCN = b'0 | Payload |
+ ------ + ----- + --------- + ---------------- +
| 8 bits | 1 bit | 1 bit | X bytes + 6 bits |
]]></artwork></figure>
</section>
<section anchor="last-fragment-all-1-1" title="Last fragment (All-1)">
<figure title="All-1 SCHC Message: the last fragment." anchor="Fig-fragmentation-downlink-header-all1"><artwork><![CDATA[
| FPort | LoRaWAN payload |
+ ------ + --------------------------- + ------------------------- +
| RuleID | W | FCN = b'1 | RCS | Payload | Opt padding |
+ ------ + ----- + --------- + ------- + ----------- + ----------- +
| 8 bits | 1 bit | 1 bit | 32 bits | 6 to X bits | 0 to 7 bits |
]]></artwork></figure>
</section>
<section anchor="schc-ack-1" title="SCHC ACK">
<figure title="SCHC ACK format, RCS is correct." anchor="Fig-frag-downlink-header-schc-ack-rcs-ok"><artwork><![CDATA[
| FPort | LoRaWAN payload |
+ ------ + ---------------------------------- +
| RuleID | W | C = b'1 | Padding b'000000 |
+ ------ + ----- + ------- + ---------------- +
| 8 bits | 1 bit | 1 bit | 6 bits |
]]></artwork></figure>
<figure title="SCHC ACK format, RCS is incorrect." anchor="Fig-frag-downlink-header-schc-ack-rcs-fail"><artwork><![CDATA[
| FPort | LoRaWAN payload |
+ ------ + ------------------------------------------------- +
| RuleID | W | C = b'0 | Bitmap = b'1 | Padding b'000000 |
+ ------ + ----- + ------- + ------------ + ---------------- +
| 8 bits | 1 bit | 1 bit | 1 bit | 5 bits |
]]></artwork></figure>
</section>
<section anchor="receiver-abort-1" title="Receiver-Abort">
<figure title="Receiver-Abort packet (following an All-1 SCHC Fragment with incorrect RCS)." anchor="Fig-fragmentation-downlink-header-abort"><artwork><![CDATA[
| FPort | LoRaWAN payload |
+ ------ + ---------------------------------------------- +
| RuleID | W = b'1 | C = b'1 | b'111111 | 0xFF (all 1's) |
+ ------ + ------- + ------- + -------- + --------------- +
| 8 bits | 1 bit | 1 bits | 6 bits | 8 bits |
next L2 Word boundary ->| <-- L2 Word --> |
]]></artwork></figure>
</section>
<section anchor="downlink-retransmission-timer" title="Downlink retransmission timer">
<t>Class A and Class B or Class C devices do not manage retransmissions and timers
the same way.</t>
<section anchor="class-a-devices" title="Class A devices">
<t>Class A devices can only receive in an RX slot following the transmission of an
uplink.</t>
<t>The SCHC gateway implements an inactivity timer with a RECOMMENDED duration
of 36 hours. For devices with very low transmission rates (example 1 packet a
day in normal operation), that duration may be extended: it is application
specific.</t>
<t>RETRANSMISSION_TIMER is application specific and its RECOMMENDED value is
INACTIVITY_TIMER/(MAX_ACK_REQUESTS + 1).</t>
<t><spanx style="strong">SCHC All-0 (FCN=0)</spanx></t>
<t>All fragments but the last have an FCN=0 (because window size is 1). Following
an All-0 SCHC Fragment, the device MUST transmit the SCHC ACK message. It MUST transmit up to
MAX_ACK_REQUESTS SCHC ACK messages before aborting. In order to progress the
fragmented datagram, the SCHC layer should immediately queue for transmission
those SCHC ACK if no SCHC downlink have been received during RX1 and RX2 window.
LoRaWAN layer will respect the applicable local spectrum regulation.</t>
<t><spanx style="emph">Note</spanx>: The ACK bitmap is 1 bit long and is always 1.</t>
<t><spanx style="strong">SCHC All-1 (FCN=1)</spanx></t>
<t>SCHC All-1 is the last fragment of a datagram, the corresponding SCHC ACK
message might be lost; therefore the SCHC gateway MUST request a retransmission
of this ACK when the retransmission timer expires. To open a downlink
opportunity the device MUST transmit an uplink every
RETRANSMISSION_TIMER/(MAX_ACK_REQUESTS * SCHC_ACK_REQ_DN_OPPORTUNITY).
The format of this uplink is application specific. It is RECOMMENDED for a
device to send an empty frame (see <xref target="lorawan-empty-frame"/>) but it is application
specific and will be used by the NGW to transmit a potential SCHC ACK REQ.<vspace />
SCHC_ACK_REQ_DN_OPPORTUNITY is application specific and its recommended value
is 2. It MUST be greater than 1. This allows to open a downlink opportunity to
any downlink with higher priority than the SCHC ACK REQ message.</t>
<t><spanx style="emph">Note</spanx>: The device MUST keep this SCHC ACK message in memory until it receives
a downlink SCHC Fragmentation Message (with FPort == FPortDown) that is not a SCHC ACK REQ: it indicates that
the SCHC gateway has received the SCHC ACK message.</t>
</section>
</section>
<section anchor="class-b-or-class-c-devices" title="Class B or Class C devices">
<t>Class B devices can receive in scheduled RX slots or in RX slots following the
transmission of an uplink. Class C devices are almost in constant reception.</t>
<t>RECOMMENDED retransmission timer value:</t>
<t><list style="symbols">
<t>Class B: 3 times the ping slot periodicity.</t>
<t>Class C: 30 seconds.</t>
</list></t>
<t>The RECOMMENDED inactivity timer value is 12 hours for both Class B and Class
C devices.</t>
</section>
</section>
</section>
<section anchor="schc-fragment-format" title="SCHC Fragment Format">
<section anchor="all-0-schc-fragment" title="All-0 SCHC fragment">
<t><spanx style="strong">Uplink fragmentation (Ack-On-Error)</spanx>:</t>
<t>All-0 is distinguishable from a SCHC ACK REQ as <xref target="RFC8724"></xref> states <spanx style="emph">This condition
is also met if the SCHC Fragment Header is a multiple of L2 Words</spanx>; this
condition met: SCHC header is 2 bytes.</t>
<t><spanx style="strong">Downlink fragmentation (Ack-always)</spanx>:</t>
<t>As per <xref target="RFC8724"></xref> the SCHC All-1 MUST contain the last tile, implementation must
ensure that SCHC All-0 message Payload will be at least the size of an L2 Word.</t>
</section>
<section anchor="all-1-schc-fragment" title="All-1 SCHC fragment">
<t>All-1 is distinguishable from a SCHC Sender-Abort as <xref target="RFC8724"></xref> states <spanx style="emph">This
condition is met if the RCS is present and is at least the size of an L2 Word</spanx>;
this condition met: RCS is 4 bytes.</t>
</section>
<section anchor="delay-after-each-lorawan-frame-to-respect-local-regulation" title="Delay after each LoRaWAN frame to respect local regulation">
<t>This profile does not define a delay to be added after each LoRaWAN frame, local
regulation compliance is expected to be enforced by LoRaWAN stack.</t>
</section>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>This document is only providing parameters that are expected to be best
suited for LoRaWAN networks for <xref target="RFC8724"></xref>. IID
security is discussed in <xref target="IID"/>. As such, this document does not contribute to
any new security issues beyond those already identified in
<xref target="RFC8724"></xref>.
Moreover, SCHC data (LoRaWAN payload) are protected at the LoRaWAN level by an AES-128
encryption with a session key shared by the device and the SCHC gateway. These session keys are renewed at each
LoRaWAN session (ie: each join or rejoin to the LoRaWAN network)</t>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>This document has no IANA actions.</t>
</section>
<section numbered="false" anchor="acknowledgements" title="Acknowledgements">
<t>Thanks to all those listed in the Contributors section for the excellent text,
insightful discussions, reviews and suggestions, and also to (in
alphabetical order) Dominique Barthel, Arunprabhu Kandasamy, Rodrigo Muñoz,
Alexander Pelov, Pascal Thubert, Laurent Toutain for useful design
considerations, reviews and comments.</t>
</section>
<section numbered="false" anchor="contributors" title="Contributors">
<t>Contributors ordered by family name.</t>
<t>Vincent Audebert<vspace />
EDF R&D<vspace />
Email: [email protected]</t>
<t>Julien Catalano<vspace />
Kerlink<vspace />
Email: [email protected]</t>
<t>Michael Coracin<vspace />
Semtech<vspace />
Email: [email protected]</t>
<t>Marc Le Gourrierec<vspace />
Sagemcom<vspace />
Email: [email protected]</t>
<t>Nicolas Sornin<vspace />
Semtech<vspace />
Email: [email protected]</t>
<t>Alper Yegin<vspace />
Actility<vspace />
Email: [email protected]</t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
<reference anchor="RFC4291" target='https://www.rfc-editor.org/info/rfc4291'>
<front>
<title>IP Version 6 Addressing Architecture</title>
<author initials='R.' surname='Hinden' fullname='R. Hinden'><organization /></author>
<author initials='S.' surname='Deering' fullname='S. Deering'><organization /></author>
<date year='2006' month='February' />
<abstract><t>This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.</t><t>This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4291'/>
<seriesInfo name='DOI' value='10.17487/RFC4291'/>
</reference>