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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
|
<pre>Internet Engineering Task Force (IETF) P. Mariager
Request for Comments: 8105 J. Petersen, Ed.
Category: Standards Track RTX A/S
ISSN: 2070-1721 Z. Shelby
ARM
M. van de Logt
Bosch Sensortec GmbH
D. Barthel
Orange Labs
May 2017
<span class="h1">Transmission of IPv6 Packets over Digital Enhanced Cordless</span>
<span class="h1">Telecommunications (DECT) Ultra Low Energy (ULE)</span>
Abstract
Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy
(ULE) is a low-power air interface technology that is proposed by the
DECT Forum and is defined and specified by ETSI.
The DECT air interface technology has been used worldwide in
communication devices for more than 20 years. It has primarily been
used to carry voice for cordless telephony but has also been deployed
for data-centric services.
DECT ULE is a recent addition to the DECT interface primarily
intended for low-bandwidth, low-power applications such as sensor
devices, smart meters, home automation, etc. As the DECT ULE
interface inherits many of the capabilities from DECT, it benefits
from operation that is long-range and interference-free, worldwide-
reserved frequency band, low silicon prices, and maturity. There is
an added value in the ability to communicate with IPv6 over DECT ULE,
such as for Internet of Things applications.
This document describes how IPv6 is transported over DECT ULE using
IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN)
techniques.
<span class="grey">Mariager, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8105">RFC 8105</a> IPv6 over DECT ULE May 2017</span>
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc8105">http://www.rfc-editor.org/info/rfc8105</a>.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Mariager, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8105">RFC 8105</a> IPv6 over DECT ULE May 2017</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-1.1">1.1</a>. Requirements Notation . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-1.2">1.2</a>. Terms Used . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2">2</a>. DECT Ultra Low Energy . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2.1">2.1</a>. The DECT ULE Protocol Stack . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2.2">2.2</a>. Link Layer Roles and Topology . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-2.3">2.3</a>. Addressing Model . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-2.4">2.4</a>. MTU Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-2.5">2.5</a>. Additional Considerations . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-3">3</a>. Specification of IPv6 over DECT ULE . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-3.1">3.1</a>. Protocol Stack . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-3.2">3.2</a>. Link Model . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-3.3">3.3</a>. Subnets and Internet Connectivity Scenarios . . . . . . . <a href="#page-15">15</a>
<a href="#section-4">4</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-5">5</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-6">6</a>. ETSI Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-7">7</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-7.1">7.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-7.2">7.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
<span class="grey">Mariager, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8105">RFC 8105</a> IPv6 over DECT ULE May 2017</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Digital Enhanced Cordless Telecommunications (DECT) is a standard
series [<a href="#ref-EN300.175-part1-7">EN300.175-part1-7</a>] specified by ETSI, and CAT-iq (Cordless
Advanced Technology - internet and quality) is a set of product
certification and interoperability profiles [<a href="#ref-CAT-iq" title=""CAT-iq at a Glance"">CAT-iq</a>] defined by DECT
Forum. DECT Ultra Low Energy (DECT ULE or just ULE) is an air
interface technology building on the key fundamentals of traditional
DECT/CAT-iq but with specific changes to significantly reduce the
power consumption at the expense of data throughput. DECT ULE
devices with requirements on power consumption, as specified by ETSI
in [<a href="#ref-TS102.939-1">TS102.939-1</a>] and [<a href="#ref-TS102.939-2">TS102.939-2</a>], will operate on special power-
optimized silicon but can connect to a DECT Gateway supporting
traditional DECT/CAT-iq for cordless telephony and data as well as
the ULE extensions.
DECT terminology has two major role definitions: the Portable Part
(PP) is the power-constrained device while the Fixed Part (FP) is the
Gateway or base station. This FP may be connected to the Internet.
An example of a use case for DECT ULE is a home-security sensor
transmitting small amounts of data (few bytes) at periodic intervals
through the FP but that is able to wake up upon an external event
(e.g., a break-in) and communicate with the FP. Another example
incorporating both DECT ULE and traditional CAT-iq telephony would be
a pendant (brooch) for the elderly that generally transmits periodic
status messages to a care provider using very little battery, but in
the event of an emergency, the elderly person can establish a voice
connection through the pendant to an alarm service. It is expected
that DECT ULE will be integrated into many residential gateways, as
many of these already implement DECT CAT-iq for cordless telephony.
DECT ULE can be added as a software option for the FP.
It is desirable to consider IPv6 for DECT ULE devices due to the
large address space and well-known infrastructure. This document
describes how IPv6 is used on DECT ULE links to optimize power while
maintaining the many benefits of IPv6 transmission. [<a href="./rfc4944" title=""Transmission of IPv6 Packets over IEEE 802.15.4 Networks"">RFC4944</a>],
[<a href="./rfc6282" title=""Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks"">RFC6282</a>], and [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>] specify the transmission of IPv6 over IEEE
802.15.4. DECT ULE has many characteristics similar to those of IEEE
802.15.4, but it also has differences. A subset of mechanisms
defined for transmission of IPv6 over IEEE 802.15.4 can be applied to
the transmission of IPv6 on DECT ULE links.
This document specifies how to map IPv6 over DECT ULE inspired by
[<a href="./rfc4944" title=""Transmission of IPv6 Packets over IEEE 802.15.4 Networks"">RFC4944</a>], [<a href="./rfc6282" title=""Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks"">RFC6282</a>], [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>], and [<a href="./rfc7668" title=""IPv6 over BLUETOOTH(R) Low Energy"">RFC7668</a>].
<span class="grey">Mariager, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8105">RFC 8105</a> IPv6 over DECT ULE May 2017</span>
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Requirements Notation</span>
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
[<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Terms Used</span>
6CO 6LoWPAN Context Option [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>]
6BBR 6loWPAN Backbone Router
6LBR 6LoWPAN Border Router, as defined in [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>].
The DECT Fixed Part has this role.
6LN 6LoWPAN Node as defined in [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>].
The DECT Portable Part has this role
6LoWPAN IPv6 over Low-Power Wireless Personal Area Network
AES128 Advanced Encryption Standard with a key size of 128 bits
API Application Programming Interface
ARO Address Registration Option [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>]
CAT-iq Cordless Advanced Technology - internet and quality
CID Context Identifier [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>]
DAC Destination Address Compression
DAD Duplicate Address Detection [<a href="./rfc4862" title=""IPv6 Stateless Address Autoconfiguration"">RFC4862</a>]
DAM Destination Address Mode
DHCPv6 Dynamic Host Configuration Protocol for IPv6 [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>]
DLC Data Link Control
DSAA2 DECT Standard Authentication Algorithm #2
DSC DECT Standard Cipher
DSC2 DECT Standard Cipher #2
FDMA Frequency-Division Multiple Access
FP DECT Fixed Part; the Gateway
GAP Generic Access Profile
IID Interface Identifier
IPEI International Portable Equipment Identity; DECT identity
MAC-48 48-bit global unique MAC address managed by IEEE
MAC Media Access Control
MTU Maximum Transmission Unit
NBMA Non-Broadcast Multi-Access
ND Neighbor Discovery [<a href="./rfc4861" title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</a>] [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>]
PDU Protocol Data Unit
PHY Physical Layer
PMID Portable MAC Identity; DECT identity
PP DECT Portable Part; typically the sensor node (6LN)
PVC Permanent Virtual Circuit
RFPI Radio Fixed Part Identity; DECT identity
SAC Source Address Compression
SAM Source Address Mode
TDD Time Division Duplex
<span class="grey">Mariager, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8105">RFC 8105</a> IPv6 over DECT ULE May 2017</span>
TDMA Time-Division Multiple Access
TPUI Temporary Portable User Identity; DECT identity
UAK User Authentication Key; DECT master security key
ULA Unique Local Address [<a href="./rfc4193" title=""Unique Local IPv6 Unicast Addresses"">RFC4193</a>]
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. DECT Ultra Low Energy</span>
DECT ULE is a low-power air interface technology that is designed to
support both circuit-switched services, such as voice communication,
and packet-mode data services at a modest data rate. This document
is only addressing the packet-mode data service of DECT ULE.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. The DECT ULE Protocol Stack</span>
The DECT ULE Protocol Stack contains a PHY layer operating at
frequencies in the 1880 - 1920 MHz frequency band depending on the
region and uses a symbol rate of 1.152 Mbaud. Radio bearers are
allocated by use of FDMA/TDMA/TDD techniques.
In its generic network topology, DECT is defined as a cellular
network technology. However, the most common configuration is a star
network with a single FP defining the network with a number of PPs
attached. The MAC layer supports both traditional DECT circuit mode
operation, as this is used for services like discovery, pairing,
security features, etc., and it supports new ULE packet-mode
operation. The circuit-mode features have been reused from DECT.
The DECT ULE device can switch to the ULE mode of operation,
utilizing the new ULE MAC layer features. The DECT ULE Data Link
Control (DLC) provides multiplexing as well as segmentation and
reassembly for larger packets from layers above. The DECT ULE layer
also implements per-message authentication and encryption. The DLC
layer ensures packet integrity and preserves packet order, but
delivery is based on best effort.
The current DECT ULE MAC layer standard supports low-bandwidth data
broadcast. However, this document is not considering usage of the
DECT ULE MAC layer broadcast service for IPv6 over DECT ULE.
In general, communication sessions can be initiated from both the FP
side and the PP side. Depending on power-down modes employed in the
PP, latency may occur when initiating sessions from the FP side. MAC
layer communication can take place using either connection-oriented
packet transfer with low overhead for short sessions or connection-
oriented bearers including media reservation. The MAC layer
autonomously selects the radio-spectrum positions that are available
<span class="grey">Mariager, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8105">RFC 8105</a> IPv6 over DECT ULE May 2017</span>
within the band and can rearrange these to avoid interference. The
MAC layer has built-in retransmission procedures in order to improve
transmission reliability.
The DECT ULE device will typically incorporate an Application
Programming Interface (API), as well as common elements known as
Generic Access Profiles (GAPs), for enrolling into the network. The
DECT ULE Stack establishes a Permanent Virtual Circuit (PVC) for the
application layers and provides support for a range of different
application protocols. The application protocol is negotiated
between the PP and FP when the PVC communication service is
established. [<a href="#ref-TS102.939-1">TS102.939-1</a>] defines this negotiation and specifies an
Application Protocol Identifier set to 0x06 for 6LoWPAN. This
document defines the behavior of that application protocol.
+----------------------------------------+
| Application Layers |
+----------------------------------------+
| Generic Access | ULE Profile |
| Profile | |
+----------------------------------------+
| DECT/Service API | ULE Data API |
+--------------------+-------------------+
| LLME | NWK (MM,CC)| |
+--------------------+-------------------+
| DECT DLC | DECT ULE DLC |
+--------------------+-------------------+
| MAC Layer |
+--------------------+-------------------+
| PHY Layer |
+--------------------+-------------------+
(C-plane) (U-plane)
Figure 1: DECT ULE Protocol Stack
Figure 1 shows the DECT ULE Stack divided into the Control Plane
(C-plane) and User Data Plane (U-plane), to the left and to the
right, respectively. The shown entities in the Stack are the
Physical Layer (PHY), Media Access Control (MAC) Layer, Data Link
Control (DLC) Layer, and Network Layer (NWK), along with following
subcomponents: Lower-Layer Management Entity (LLME), Mobility
Management (MM), and Call Control (CC). Above there are the typical
Application Programmers Interface (API) and application-profile-
specific layers.
<span class="grey">Mariager, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8105">RFC 8105</a> IPv6 over DECT ULE May 2017</span>
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Link Layer Roles and Topology</span>
An FP is assumed to be less constrained than a PP. Hence, in the
primary scenario, the FP and PP will act as 6LBR and a 6LN,
respectively. This document only addresses this primary scenario,
and all other scenarios with different roles of an FP and PP are out
of scope.
In DECT ULE, at the link layer, the communication only takes place
between an FP and a PP. An FP is able to handle multiple
simultaneous connections with a number of PPs. Hence, in a DECT ULE
network using IPv6, a radio hop is equivalent to an IPv6 link and
vice versa (see <a href="#section-3.3">Section 3.3</a>).
[DECT ULE PP]-----\ /-----[DECT ULE PP]
\ /
[DECT ULE PP]-------+[DECT ULE FP]+-------[DECT ULE PP]
/ \
[DECT ULE PP]-----/ \-----[DECT ULE PP]
Figure 2: DECT ULE Star Topology
A significant difference between IEEE 802.15.4 and DECT ULE is that
the former supports both star and mesh topology (and requires a
routing protocol), whereas DECT ULE in its primary configuration does
not support the formation of multihop networks at the link layer. In
consequence, the mesh header defined in [<a href="./rfc4944" title=""Transmission of IPv6 Packets over IEEE 802.15.4 Networks"">RFC4944</a>] is not used in DECT
ULE networks.
DECT ULE repeaters are considered to operate transparently in the
DECT protocol domain and are outside the scope of this document.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Addressing Model</span>
Each DECT PP is assigned an IPEI during manufacturing. This identity
has the size of 40 bits and is globally unique within DECT addressing
space and can be used to constitute the MAC address used to derive
the IID for link-local address.
During a DECT location registration procedure, the FP assigns a
20-bit TPUI to a PP. The FP creates a unique mapping between the
assigned TPUI and the IPEI of each PP. This TPUI is used for
addressing (Layer 2) in messages between the FP and PP. Although the
TPUI is temporary by definition, many implementations assign the same
value repeatedly to any given PP, hence it seems not suitable for
construction of the IID (see [<a href="./rfc8065" title=""Privacy Considerations for IPv6 Adaptation- Layer Mechanisms"">RFC8065</a>]).
<span class="grey">Mariager, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8105">RFC 8105</a> IPv6 over DECT ULE May 2017</span>
Each DECT FP is assigned an RFPI during manufacturing. This identity
has the size of 40 bits and is globally unique within DECT addressing
space and can be used to constitute the MAC address used to derive
the IID for link-local address.
Optionally, each DECT PP and DECT FP can be assigned a unique (IEEE)
MAC-48 address in addition to the DECT identities to be used by the
6LoWPAN. During the address registration of non-link-local addresses
as specified by this document, the FP and PP can use such MAC-48 to
construct the IID. However, as these addresses are considered as
being permanent, such a scheme is NOT RECOMMENDED as per [<a href="./rfc8065" title=""Privacy Considerations for IPv6 Adaptation- Layer Mechanisms"">RFC8065</a>].
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. MTU Considerations</span>
Ideally, the DECT ULE FP and PP may generate data that fits into a
single MAC layer packet (38 octets) for periodically transferred
information, depending on application. However, IP packets may be
much larger. The DECT ULE DLC procedures natively support
segmentation and reassembly and provide any MTU size below 65536
octets. The default MTU size defined in DECT ULE [<a href="#ref-TS102.939-1">TS102.939-1</a>] is
500 octets. In order to support complete IPv6 packets, the DLC layer
of DECT ULE SHALL, per this specification, be configured with an MTU
size of 1280 octets, hence [<a href="./rfc4944" title=""Transmission of IPv6 Packets over IEEE 802.15.4 Networks"">RFC4944</a>] fragmentation/reassembly is not
required.
It is important to realize that the usage of larger packets will be
at the expense of battery life, as a large packet inside the DECT ULE
Stack will be fragmented into several or many MAC layer packets, each
consuming power to transmit/receive. The increased MTU size does not
change the MAC layer packet and PDU size.
<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>. Additional Considerations</span>
The DECT ULE standard allows the PP to be DECT-registered (bound) to
multiple FP and to roam between them. These FP and their 6LBR
functionalities can operate either individually or connected through
a Backbone Router as per [<a href="#ref-BACKBONE-ROUTER">BACKBONE-ROUTER</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Specification of IPv6 over DECT ULE</span>
Before any IP-layer communications can take place over DECT ULE,
DECT-ULE-enabled nodes such as 6LNs and 6LBRs have to find each other
and establish a suitable link layer connection. The obtain-access-
rights registration and location registration procedures are
documented by ETSI in the specifications [<a href="#ref-EN300.175-part1-7">EN300.175-part1-7</a>],
[<a href="#ref-TS102.939-1">TS102.939-1</a>], and [<a href="#ref-TS102.939-2">TS102.939-2</a>].
<span class="grey">Mariager, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8105">RFC 8105</a> IPv6 over DECT ULE May 2017</span>
DECT ULE technology sets strict requirements for low power
consumption and, thus, limits the allowed protocol overhead. 6LoWPAN
standards [<a href="./rfc4944" title=""Transmission of IPv6 Packets over IEEE 802.15.4 Networks"">RFC4944</a>], [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>], and [<a href="./rfc6282" title=""Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks"">RFC6282</a>] provide useful
functionality for reducing overhead that can be applied to DECT ULE.
This functionality comprises link-local IPv6 addresses and stateless
IPv6 address autoconfiguration, Neighbor Discovery, and header
compression.
The ULE 6LoWPAN adaptation layer can run directly on this U-plane DLC
layer. Figure 3 illustrates an IPv6 over DECT ULE Stack.
Because DECT ULE in its primary configuration does not support the
formation of multihop networks at the link layer, the mesh header
defined in [<a href="./rfc4944" title=""Transmission of IPv6 Packets over IEEE 802.15.4 Networks"">RFC4944</a>] for mesh under routing MUST NOT be used. In
addition, the role of a 6LoWPAN Router (6LR) is not defined per this
specification.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Protocol Stack</span>
In order to enable data transmission over DECT ULE, a Permanent
Virtual Circuit (PVC) has to be configured and opened between the FP
and PP. This is done by setting up a DECT service call between the
PP and FP. In the DECT protocol domain, the PP SHALL specify the
<<IWU-ATTRIBUTES>> in a service-change (other) message before sending
a service-change (resume) message as defined in [<a href="#ref-TS102.939-1">TS102.939-1</a>]. The
<<IWU-ATTRIBUTES>> SHALL set the ULE Application Protocol Identifier
to 0x06 and the MTU size to 1280 octets or larger. The FP sends a
service-change-accept (resume) that MUST contain a valid paging
descriptor. The PP MUST listen to paging messages from the FP
according to the information in the received paging descriptor.
Following this, transmission of IPv6 packets can start.
+-------------------+
| UDP/TCP/other |
+-------------------+
| IPv6 |
+-------------------+
|6LoWPAN adapted to |
| DECT ULE |
+-------------------+
| DECT ULE DLC |
+-------------------+
| DECT ULE MAC |
+-------------------+
| DECT ULE PHY |
+-------------------+
Figure 3: IPv6 over DECT ULE Stack
<span class="grey">Mariager, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8105">RFC 8105</a> IPv6 over DECT ULE May 2017</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Link Model</span>
The general model is that IPv6 is Layer 3 and DECT ULE MAC and DECT
ULE DLC are Layer 2. DECT ULE already implements fragmentation and
reassembly functionality; hence, the fragmentation and reassembly
function described in [<a href="./rfc4944" title=""Transmission of IPv6 Packets over IEEE 802.15.4 Networks"">RFC4944</a>] MUST NOT be used.
After the FPs and PPs have connected at the DECT ULE level, the link
can be considered up and IPv6 address configuration and transmission
can begin. The 6LBR ensures address collisions do not occur.
Per this specification, the IPv6 header compression format specified
in [<a href="./rfc6282" title=""Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks"">RFC6282</a>] MUST be used. The IPv6 payload length can be derived
from the ULE DLC packet length. The possibly elided IPv6 address can
be reconstructed from the lower layer address (see <a href="#section-3.2.4">Section 3.2.4</a>).
Due to the DECT ULE star topology (see <a href="#section-2.2">Section 2.2</a>), each PP has a
separate link to the FP; thus, the PPs cannot directly hear one
another and cannot talk to one another. As discussed in [<a href="./rfc4903" title=""Multi-Link Subnet Issues"">RFC4903</a>],
conventional usage of IPv6 anticipates IPv6 subnets spanning a single
link at the link layer. In order to avoid the complexity of
implementing a separate subnet for each DECT ULE link, a Multi-Link
Subnet model [<a href="./rfc4903" title=""Multi-Link Subnet Issues"">RFC4903</a>] has been chosen, specifically Non-Broadcast
Multi-Access (NBMA) at Layer 2. Because of this, link-local
multicast communications can happen only within a single DECT ULE
connection; thus, 6LN-to-6LN communications using link-local
addresses are not possible. 6LNs connected to the same 6LBR have to
communicate with each other utilizing the shared prefix used on the
subnet. The 6LBR forwards packets sent by one 6LN to another.
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. Stateless Address Autoconfiguration</span>
At network interface initialization, both 6LN and 6LBR SHALL generate
and assign IPv6 link-local addresses to the DECT ULE network
interfaces [<a href="./rfc4862" title=""IPv6 Stateless Address Autoconfiguration"">RFC4862</a>] based on the DECT device addresses (see
<a href="#section-2.3">Section 2.3</a>) that were used for establishing the underlying DECT ULE
connection.
The DECT device addresses IPEI and RFPI MUST be used to derive the
IPv6 link-local 64-bit Interface Identifiers (IIDs) for 6LN and 6LBR,
respectively.
The rule for deriving IIDs from DECT device addresses is as follows:
the DECT device addresses that consist of 40 bits each MUST be
expanded with leading zero bits to form 48-bit intermediate
addresses. The most significant bit in this newly formed 48-bit
intermediate address is set to one for addresses derived from the
RFPI and set to zero for addresses derived from the IPEI. 64-bit IIDs
<span class="grey">Mariager, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8105">RFC 8105</a> IPv6 over DECT ULE May 2017</span>
are derived from these intermediate 48-bit addresses following the
guidance in <a href="./rfc4291#appendix-A">Appendix A of [RFC4291]</a>. However, because DECT and IEEE
address spaces are different, this intermediate address cannot be
considered to be unique within an IEEE address space. In the derived
IIDs, the Universal/Local (U/L) bit (7th bit) will be zero, which
indicates that derived IIDs are not globally unique, see [<a href="./rfc7136" title=""Significance of IPv6 Interface Identifiers"">RFC7136</a>].
For example, from RFPI=11.22.33.44.55, the derived IID is
80:11:22:ff:fe:33:44:55; from IPEI=01.23.45.67.89, the derived IID is
00:01:23:ff:fe:45:67:89.
Global uniqueness of an IID in link-local addresses is not required
as they should never be leaked outside the subnet domain.
As defined in [<a href="./rfc4291" title=""IP Version 6 Addressing Architecture"">RFC4291</a>], the IPv6 link-local address is formed by
appending the IID to the prefix FE80::/64, as shown in Figure 4.
10 bits 54 bits 64 bits
+----------+-----------------+----------------------+
|1111111010| zeros | Interface Identifier |
+----------+-----------------+----------------------+
Figure 4: IPv6 Link-Local Address in DECT ULE
A 6LN MUST join the all-nodes multicast address.
After link-local address configuration, 6LN sends Router Solicitation
messages as described in <a href="./rfc4861#section-6.3.7">Section 6.3.7 of [RFC4861]</a> and <a href="./rfc6775#section-5.3">Section 5.3
of [RFC6775]</a>.
For non-link-local addresses, 6LNs SHOULD NOT be configured to use
IIDs derived from a MAC-48 device address or DECT device addresses.
Alternative schemes such as Cryptographically Generated Addresses
(CGAs) [<a href="./rfc3972" title=""Cryptographically Generated Addresses (CGA)"">RFC3972</a>], privacy extensions [<a href="./rfc4941" title=""Privacy Extensions for Stateless Address Autoconfiguration in IPv6"">RFC4941</a>], Hash-Based Addresses
(HBAs) [<a href="./rfc5535" title=""Hash-Based Addresses (HBA)"">RFC5535</a>], DHCPv6 [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>], or static, semantically opaque
addresses [<a href="./rfc7217" title=""A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)"">RFC7217</a>] SHOULD be used by default. See also [<a href="./rfc8065" title=""Privacy Considerations for IPv6 Adaptation- Layer Mechanisms"">RFC8065</a>]
for guidance of needed entropy in IIDs and the recommended lifetime
of used IIDs. When generated IIDs are not globally unique, Duplicate
Address Detection (DAD) [<a href="./rfc4862" title=""IPv6 Stateless Address Autoconfiguration"">RFC4862</a>] MUST be used. In situations where
deployment constraints require the device's address to be embedded in
the IID, the 6LN MAY form a 64-bit IID by utilizing the MAC-48 device
address or DECT device addresses. The non-link-local addresses that
a 6LN generates MUST be registered with 6LBR as described in
<a href="#section-3.2.2">Section 3.2.2</a>.
The means for a 6LBR to obtain an IPv6 prefix for numbering the DECT
ULE network is out of scope of this document, but a prefix can be,
for example, assigned via DHCPv6 Prefix Delegation [<a href="./rfc3633" title=""IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6"">RFC3633</a>] or using
IPv6 Unicast Unique Local Addresses (ULAs) [<a href="./rfc4193" title=""Unique Local IPv6 Unicast Addresses"">RFC4193</a>]. Due to the
<span class="grey">Mariager, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8105">RFC 8105</a> IPv6 over DECT ULE May 2017</span>
link model of the DECT ULE, the 6LBR MUST set the "on-link" (L) flag
to zero in the Prefix Information Option [<a href="./rfc4861" title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</a>]. This will cause
6LNs to always send packets to the 6LBR, including the case when the
destination is another 6LN using the same prefix.
<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>. Neighbor Discovery</span>
"Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)" [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>] describes the Neighbor
Discovery approach as adapted for use in several 6LoWPAN topologies,
including the mesh topology. As DECT ULE does not support mesh
networks, only those aspects of [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>] that apply to star topology
are considered.
The following aspects of the Neighbor Discovery optimizations
[<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>] are applicable to DECT ULE 6LNs:
1. For sending Router Solicitations and processing Router
Advertisements the DECT ULE 6LNs MUST, respectively, follow
Sections <a href="#section-5.3">5.3</a> and <a href="#section-5.4">5.4</a> of the [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>].
2. A DECT ULE 6LN MUST NOT register its link-local address. Because
the IIDs used in link-local addresses are derived from DECT
addresses, there will always exist a unique mapping between link-
local and Layer 2 addresses.
3. A DECT ULE 6LN MUST register its non-link-local addresses with
the 6LBR by sending a Neighbor Solicitation (NS) message with the
Address Registration Option (ARO) and process the Neighbor
Advertisement (NA) accordingly. The NS with the ARO option MUST
be sent irrespective of the method used to generate the IID.
<span class="h4"><a class="selflink" id="section-3.2.3" href="#section-3.2.3">3.2.3</a>. Unicast and Multicast Address Mapping</span>
The DECT MAC layer broadcast service is considered inadequate for IP
multicast because it does not support the MTU size required by IPv6.
Hence, traffic is always unicast between two DECT ULE nodes. Even in
the case where a 6LBR is attached to multiple 6LNs, the 6LBR cannot
do a multicast to all the connected 6LNs. If the 6LBR needs to send
a multicast packet to all its 6LNs, it has to replicate the packet
and unicast it on each link. However, this may not be energy
efficient and particular care should be taken if the FP is battery-
powered. To further conserve power, the 6LBR MUST keep track of
multicast listeners at DECT ULE link-level granularity, and it MUST
NOT forward multicast packets to 6LNs that have not registered for
multicast groups the packets belong to. In the opposite direction, a
6LN can only transmit data to or through the 6LBR. Hence, when a 6LN
<span class="grey">Mariager, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8105">RFC 8105</a> IPv6 over DECT ULE May 2017</span>
needs to transmit an IPv6 multicast packet, the 6LN will unicast the
corresponding DECT ULE packet to the 6LBR. The 6LBR will then
forward the multicast packet to other 6LNs.
<span class="h4"><a class="selflink" id="section-3.2.4" href="#section-3.2.4">3.2.4</a>. Header Compression</span>
As defined in [<a href="./rfc6282" title=""Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks"">RFC6282</a>], which specifies the compression format for
IPv6 datagrams on top of IEEE 802.15.4, header compression is
REQUIRED in this document as the basis for IPv6 header compression on
top of DECT ULE. All headers MUST be compressed according to
encoding formats as described in [<a href="./rfc6282" title=""Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks"">RFC6282</a>]. The DECT ULE's star
topology structure, ARO and 6CO, can be exploited in order to provide
a mechanism for address compression. The following text describes
the principles of IPv6 address compression on top of DECT ULE.
<span class="h5"><a class="selflink" id="section-3.2.4.1" href="#section-3.2.4.1">3.2.4.1</a>. Link-Local Header Compression</span>
In a link-local communication terminated at 6LN and 6LBR, both the
IPv6 source and destination addresses MUST be elided since the used
IIDs map uniquely into the DECT link end-point addresses. A 6LN or
6LBR that receives a PDU containing an IPv6 packet can infer the
corresponding IPv6 source address. For the unicast type of
communication considered in this paragraph, the following settings
MUST be used in the IPv6 compressed header: CID=0, SAC=0, SAM=11,
DAC=0, and DAM=11.
<span class="h5"><a class="selflink" id="section-3.2.4.2" href="#section-3.2.4.2">3.2.4.2</a>. Non-link-local Header Compression</span>
To enable efficient header compression, the 6LBR MUST include the
6LoWPAN Context Option (6CO) [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>] for all prefixes the 6LBR
advertises in Router Advertisements for use in stateless address
autoconfiguration.
When a 6LN transmits an IPv6 packet to a destination using global
unicast IPv6 addresses, if a context is defined for the prefix of the
6LNs global IPv6 address, the 6LN MUST indicate this context in the
corresponding source fields of the compressed IPv6 header as per
<a href="./rfc6282#section-3.1">Section 3.1 of [RFC6282]</a> and MUST fully elide the latest registered
IPv6 source address. For this, the 6LN MUST use the following
settings in the IPv6 compressed header: CID=1, SAC=1, and SAM=11. In
this case, the 6LBR can infer the elided IPv6 source address since 1)
the 6LBR has previously assigned the prefix to the 6LNs and 2) the
6LBR maintains a Neighbor Cache that relates the device address and
the IID of the corresponding PP. If a context is defined for the
IPv6 destination address, the 6LN MUST also indicate this context in
the corresponding destination fields of the compressed IPv6 header
and MUST elide the prefix of the destination IPv6 address. For this,
the 6LN MUST set the DAM field of the compressed IPv6 header as
<span class="grey">Mariager, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8105">RFC 8105</a> IPv6 over DECT ULE May 2017</span>
CID=1, DAC=1, and DAM=01 or DAM=11. Note that when a context is
defined for the IPv6 destination address, the 6LBR can infer the
elided destination prefix by using the context.
When a 6LBR receives an IPv6 packet having a global unicast IPv6
address and the destination of the packet is a 6LN, if a context is
defined for the prefix of the 6LN's global IPv6 address, the 6LBR
MUST indicate this context in the corresponding destination fields of
the compressed IPv6 header and MUST fully elide the IPv6 destination
address of the packet if the destination address is the latest
registered by the 6LN for the indicated context. For this, the 6LBR
MUST set the DAM field of the IPv6 compressed header as DAM=11. CID
and DAC MUST be set to CID=1 and DAC=1. If a context is defined for
the prefix of the IPv6 source address, the 6LBR MUST indicate this
context in the source fields of the compressed IPv6 header and MUST
elide that prefix as well. For this, the 6LBR MUST set the SAM field
of the IPv6 compressed header as CID=1, SAC=1, and SAM=01 or SAM=11.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Subnets and Internet Connectivity Scenarios</span>
In the DECT ULE star topology (see <a href="#section-2.2">Section 2.2</a>), each PP has a
separate link to the FP, and the FP acts as an IPv6 router rather
than a link layer switch. A Multi-Link Subnet model [<a href="./rfc4903" title=""Multi-Link Subnet Issues"">RFC4903</a>] has
been chosen, specifically Non-Broadcast Multi-Access (NBMA) at Layer
2, as is further illustrated in Figure 5. The 6LBR forwards packets
sent by one 6LN to another. In a typical scenario, the DECT ULE
network is connected to the Internet as shown in the Figure 5. In
this scenario, the DECT ULE network is deployed as one subnet using
one /64 IPv6 prefix. The 6LBR acts as a router and forwards packets
between 6LNs to and from Internet.
6LN
\ ____________
\ / \
6LN ---- 6LBR ------ | Internet |
/ \____________/
/
6LN
<-- One subnet -->
<-- DECT ULE -->
Figure 5: DECT ULE Network Connected to the Internet
In some scenarios, the DECT ULE network may transiently or
permanently be an isolated network as shown in the Figure 6. In this
case, the whole DECT ULE network consists of a single subnet with
multiple links, where 6LBR is routing packets between 6LNs.
<span class="grey">Mariager, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc8105">RFC 8105</a> IPv6 over DECT ULE May 2017</span>
6LN 6LN
\ /
\ /
6LN --- 6LBR --- 6LN
/ \
/ \
6LN 6LN
<---- One subnet ---->
<------ DECT ULE ----->
Figure 6: Isolated DECT ULE Network
In the isolated network scenario, communications between 6LN and 6LBR
can use IPv6 link-local methodology, but for communications between
different PP, the FP has to act as 6LBR, number the network with a
ULA prefix [<a href="./rfc4193" title=""Unique Local IPv6 Unicast Addresses"">RFC4193</a>], and route packets between the PP.
In other more advanced systems scenarios with multiple FPs and 6LBR,
each DECT ULE FP constitutes a wireless cell. The network can be
configured as a Multi-Link Subnet in which the 6LN can operate within
the same /64 subnet prefix in multiple cells as shown in the
Figure 7. The FPs in such a scenario should behave as Backbone
Routers (6BBR) as defined in [<a href="#ref-BACKBONE-ROUTER">BACKBONE-ROUTER</a>].
____________
/ \
| Internet |
\____________/
|
|
|
|
6BBR/ | 6BBR/
6LN ---- 6LBR -------+------- 6LBR ---- 6LN
/ \ / \
/ \ / \
6LN 6LN 6LN 6LN
<------------------ One subnet ------------------>
<-- DECT ULE Cell --> <-- DECT ULE Cell -->
Figure 7: Multiple DECT ULE Cells in a Single Multi-link Subnet
<span class="grey">Mariager, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc8105">RFC 8105</a> IPv6 over DECT ULE May 2017</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IANA Considerations</span>
This document does not require any IANA actions.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
The secure transmission of circuit mode services in DECT is based on
the DSAA2 and DSC/DSC2 specifications developed by ETSI Technical
Committee (TC) DECT and the ETSI Security Algorithms Group of Experts
(SAGE).
DECT ULE communications are secured at the link layer (DLC) by
encryption and per-message authentication through CCM (Counter with
Cipher Block Chaining Message Authentication Code (CBC-MAC)) mode
similar to [<a href="./rfc3610" title=""Counter with CBC-MAC (CCM)"">RFC3610</a>]. The underlying algorithm for providing
encryption and authentication is AES128.
The DECT ULE pairing procedure generates a master User Authentication
Key (UAK). During the location registration procedure, or when the
permanent virtual circuits are established, the session security keys
are generated. Both the master authentication key and session
security keys are generated by use of the DSAA2 algorithm
[<a href="#ref-EN300.175-part1-7">EN300.175-part1-7</a>], which uses AES128 as the underlying algorithm.
Session security keys may be renewed regularly. The generated
security keys (UAK and session security keys) are individual for each
FP-PP binding; hence, all PPs in a system have different security
keys. DECT ULE PPs do not use any shared encryption key.
Even though DECT ULE offers link layer security, it is still
recommended to use secure transport or application protocols above
6LoWPAN.
From the privacy point of view, the IPv6 link-local address
configuration described in <a href="#section-3.2.1">Section 3.2.1</a> only reveals information
about the 6LN to the 6LBR that the 6LBR already knows from the link
layer connection. For non-link-local IPv6 addresses, by default, a
6LN SHOULD use a randomly generated IID, for example, as discussed in
[<a href="./rfc8064" title=""Recommendation on Stable IPv6 Interface Identifiers"">RFC8064</a>], or use alternative schemes such as Cryptographically
Generated Addresses (CGAs) [<a href="./rfc3972" title=""Cryptographically Generated Addresses (CGA)"">RFC3972</a>], privacy extensions [<a href="./rfc4941" title=""Privacy Extensions for Stateless Address Autoconfiguration in IPv6"">RFC4941</a>],
Hash-Based Addresses (HBAs, [<a href="./rfc5535" title=""Hash-Based Addresses (HBA)"">RFC5535</a>]), or static, semantically
opaque addresses [<a href="./rfc7217" title=""A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)"">RFC7217</a>].
<span class="grey">Mariager, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc8105">RFC 8105</a> IPv6 over DECT ULE May 2017</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. ETSI Considerations</span>
ETSI is standardizing a list of known application-layer protocols
that can use the DECT ULE permanent virtual circuit packet data
service. Each protocol is identified by a unique known identifier,
which is exchanged in the service-change procedure as defined in
[<a href="#ref-TS102.939-1">TS102.939-1</a>]. The IPv6/6LoWPAN as described in this document is
considered to be an application-layer protocol on top of DECT ULE.
In order to provide interoperability between 6LoWPAN / DECT ULE
devices, a common protocol identifier for 6LoWPAN is standardized by
ETSI.
The ETSI DECT ULE Application Protocol Identifier is set to 0x06 for
6LoWPAN [<a href="#ref-TS102.939-1">TS102.939-1</a>].
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-EN300.175-part1-7">EN300.175-part1-7</a>]
ETSI, "Digital Enhanced Cordless Telecommunications
(DECT); Common Interface (CI); Part 1: Overview", European
Standard, ETSI EN 300 175-1, V2.6.1, July 2015,
<<a href="https://www.etsi.org/deliver/etsi_en/300100_300199/30017501/02.06.01_60/en_30017501v020601p.pdf">https://www.etsi.org/deliver/</a>
<a href="https://www.etsi.org/deliver/etsi_en/300100_300199/30017501/02.06.01_60/en_30017501v020601p.pdf">etsi_en/300100_300199/30017501/02.06.01_60/</a>
<a href="https://www.etsi.org/deliver/etsi_en/300100_300199/30017501/02.06.01_60/en_30017501v020601p.pdf">en_30017501v020601p.pdf</a>>.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC3633">RFC3633</a>] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", <a href="./rfc3633">RFC 3633</a>,
DOI 10.17487/RFC3633, December 2003,
<<a href="http://www.rfc-editor.org/info/rfc3633">http://www.rfc-editor.org/info/rfc3633</a>>.
[<a id="ref-RFC4193">RFC4193</a>] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", <a href="./rfc4193">RFC 4193</a>, DOI 10.17487/RFC4193, October 2005,
<<a href="http://www.rfc-editor.org/info/rfc4193">http://www.rfc-editor.org/info/rfc4193</a>>.
[<a id="ref-RFC4291">RFC4291</a>] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", <a href="./rfc4291">RFC 4291</a>, DOI 10.17487/RFC4291, February
2006, <<a href="http://www.rfc-editor.org/info/rfc4291">http://www.rfc-editor.org/info/rfc4291</a>>.
<span class="grey">Mariager, et al. Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc8105">RFC 8105</a> IPv6 over DECT ULE May 2017</span>
[<a id="ref-RFC4861">RFC4861</a>] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", <a href="./rfc4861">RFC 4861</a>,
DOI 10.17487/RFC4861, September 2007,
<<a href="http://www.rfc-editor.org/info/rfc4861">http://www.rfc-editor.org/info/rfc4861</a>>.
[<a id="ref-RFC4862">RFC4862</a>] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", <a href="./rfc4862">RFC 4862</a>,
DOI 10.17487/RFC4862, September 2007,
<<a href="http://www.rfc-editor.org/info/rfc4862">http://www.rfc-editor.org/info/rfc4862</a>>.
[<a id="ref-RFC4941">RFC4941</a>] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", <a href="./rfc4941">RFC 4941</a>, DOI 10.17487/RFC4941, September 2007,
<<a href="http://www.rfc-editor.org/info/rfc4941">http://www.rfc-editor.org/info/rfc4941</a>>.
[<a id="ref-RFC4944">RFC4944</a>] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", <a href="./rfc4944">RFC 4944</a>, DOI 10.17487/RFC4944, September 2007,
<<a href="http://www.rfc-editor.org/info/rfc4944">http://www.rfc-editor.org/info/rfc4944</a>>.
[<a id="ref-RFC6282">RFC6282</a>] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", <a href="./rfc6282">RFC 6282</a>,
DOI 10.17487/RFC6282, September 2011,
<<a href="http://www.rfc-editor.org/info/rfc6282">http://www.rfc-editor.org/info/rfc6282</a>>.
[<a id="ref-RFC6775">RFC6775</a>] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
<a href="./rfc6775">RFC 6775</a>, DOI 10.17487/RFC6775, November 2012,
<<a href="http://www.rfc-editor.org/info/rfc6775">http://www.rfc-editor.org/info/rfc6775</a>>.
[<a id="ref-RFC7136">RFC7136</a>] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", <a href="./rfc7136">RFC 7136</a>, DOI 10.17487/RFC7136,
February 2014, <<a href="http://www.rfc-editor.org/info/rfc7136">http://www.rfc-editor.org/info/rfc7136</a>>.
[<a id="ref-TS102.939-1">TS102.939-1</a>]
ETSI, "Digital Enhanced Cordless Telecommunications
(DECT); Ultra Low Energy (ULE); Machine to Machine
Communications; Part 1: Home Automation Network (phase
1)", Technical Specification, ETSI TS 102 939-1, V1.2.1,
March 2015, <<a href="https://www.etsi.org/deliver/etsi_ts/102900_102999/10293901/01.02.01_60/ts_10293901v010201p.pdf">https://www.etsi.org/deliver/</a>
<a href="https://www.etsi.org/deliver/etsi_ts/102900_102999/10293901/01.02.01_60/ts_10293901v010201p.pdf">etsi_ts/102900_102999/10293901/01.02.01_60/</a>
<a href="https://www.etsi.org/deliver/etsi_ts/102900_102999/10293901/01.02.01_60/ts_10293901v010201p.pdf">ts_10293901v010201p.pdf</a>>.
<span class="grey">Mariager, et al. Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc8105">RFC 8105</a> IPv6 over DECT ULE May 2017</span>
[<a id="ref-TS102.939-2">TS102.939-2</a>]
ETSI, "Digital Enhanced Cordless Telecommunications
(DECT); Ultra Low Energy (ULE); Machine to Machine
Communications; Part 2: Home Automation Network (phase
2)", Technical Specification, ETSI TS 102 939-2, V1.1.1,
March 2015, <<a href="https://www.etsi.org/deliver/etsi_ts/102900_102999/10293902/01.01.01_60/ts_10293902v010101p.pdf">https://www.etsi.org/deliver/</a>
<a href="https://www.etsi.org/deliver/etsi_ts/102900_102999/10293902/01.01.01_60/ts_10293902v010101p.pdf">etsi_ts/102900_102999/10293902/01.01.01_60/</a>
<a href="https://www.etsi.org/deliver/etsi_ts/102900_102999/10293902/01.01.01_60/ts_10293902v010101p.pdf">ts_10293902v010101p.pdf</a>>.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-BACKBONE-ROUTER">BACKBONE-ROUTER</a>]
Thubert, P., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22IPv6+Backbone+Router%22'>"IPv6 Backbone Router"</a>, Work in Progress,
<a href="./draft-ietf-6lo-backbone-router-03">draft-ietf-6lo-backbone-router-03</a>, January 2017.
[<a id="ref-CAT-iq">CAT-iq</a>] DECT Forum, "CAT-iq at a Glance", January 2016,
<<a href="http://www.dect.org/userfiles/Public/DF_CAT-iq%20at%20a%20Glance.pdf">http://www.dect.org/userfiles/Public/</a>
<a href="http://www.dect.org/userfiles/Public/DF_CAT-iq%20at%20a%20Glance.pdf">DF_CAT-iq%20at%20a%20Glance.pdf</a>>.
[<a id="ref-RFC3315">RFC3315</a>] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", <a href="./rfc3315">RFC 3315</a>, DOI 10.17487/RFC3315, July
2003, <<a href="http://www.rfc-editor.org/info/rfc3315">http://www.rfc-editor.org/info/rfc3315</a>>.
[<a id="ref-RFC3610">RFC3610</a>] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", <a href="./rfc3610">RFC 3610</a>, DOI 10.17487/RFC3610, September
2003, <<a href="http://www.rfc-editor.org/info/rfc3610">http://www.rfc-editor.org/info/rfc3610</a>>.
[<a id="ref-RFC3972">RFC3972</a>] Aura, T., "Cryptographically Generated Addresses (CGA)",
<a href="./rfc3972">RFC 3972</a>, DOI 10.17487/RFC3972, March 2005,
<<a href="http://www.rfc-editor.org/info/rfc3972">http://www.rfc-editor.org/info/rfc3972</a>>.
[<a id="ref-RFC4903">RFC4903</a>] Thaler, D., "Multi-Link Subnet Issues", <a href="./rfc4903">RFC 4903</a>,
DOI 10.17487/RFC4903, June 2007,
<<a href="http://www.rfc-editor.org/info/rfc4903">http://www.rfc-editor.org/info/rfc4903</a>>.
[<a id="ref-RFC5535">RFC5535</a>] Bagnulo, M., "Hash-Based Addresses (HBA)", <a href="./rfc5535">RFC 5535</a>,
DOI 10.17487/RFC5535, June 2009,
<<a href="http://www.rfc-editor.org/info/rfc5535">http://www.rfc-editor.org/info/rfc5535</a>>.
[<a id="ref-RFC7217">RFC7217</a>] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", <a href="./rfc7217">RFC 7217</a>,
DOI 10.17487/RFC7217, April 2014,
<<a href="http://www.rfc-editor.org/info/rfc7217">http://www.rfc-editor.org/info/rfc7217</a>>.
<span class="grey">Mariager, et al. Standards Track [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc8105">RFC 8105</a> IPv6 over DECT ULE May 2017</span>
[<a id="ref-RFC7668">RFC7668</a>] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", <a href="./rfc7668">RFC 7668</a>, DOI 10.17487/RFC7668, October 2015,
<<a href="http://www.rfc-editor.org/info/rfc7668">http://www.rfc-editor.org/info/rfc7668</a>>.
[<a id="ref-RFC8064">RFC8064</a>] Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers",
<a href="./rfc8064">RFC 8064</a>, DOI 10.17487/RFC8064, February 2017,
<<a href="http://www.rfc-editor.org/info/rfc8064">http://www.rfc-editor.org/info/rfc8064</a>>.
[<a id="ref-RFC8065">RFC8065</a>] Thaler, D., "Privacy Considerations for IPv6 Adaptation-
Layer Mechanisms", <a href="./rfc8065">RFC 8065</a>, DOI 10.17487/RFC8065,
February 2017, <<a href="http://www.rfc-editor.org/info/rfc8065">http://www.rfc-editor.org/info/rfc8065</a>>.
Acknowledgements
We are grateful to the members of the IETF 6lo working group; this
document borrows liberally from their work.
Ralph Droms, Samita Chakrabarti, Kerry Lynn, Suresh Krishnan, Pascal
Thubert, Tatuya Jinmei, Dale Worley, and Robert Sparks have provided
valuable feedback for this document.
<span class="grey">Mariager, et al. Standards Track [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc8105">RFC 8105</a> IPv6 over DECT ULE May 2017</span>
Authors' Addresses
Peter B. Mariager
RTX A/S
Stroemmen 6
DK-9400 Noerresundby
Denmark
Email: pm@rtx.dk
Jens Toftgaard Petersen (editor)
RTX A/S
Stroemmen 6
DK-9400 Noerresundby
Denmark
Email: jtp@rtx.dk
Zach Shelby
ARM
150 Rose Orchard
San Jose, CA 95134
United States of America
Email: zach.shelby@arm.com
Marco van de Logt
Bosch Sensortec GmbH
Gerhard-Kindler-Str. 9
72770 Reutlingen
Germany
Email: marco.vandelogt@bosch-sensortec.com
Dominique Barthel
Orange Labs
28 chemin du Vieux Chene
38243 Meylan
France
Email: dominique.barthel@orange.com
Mariager, et al. Standards Track [Page 22]
</pre>
|
