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
|
<pre>Internet Engineering Task Force (IETF) A. Brandt
Request for Comments: 7428 J. Buron
Category: Standards Track Sigma Designs
ISSN: 2070-1721 February 2015
<span class="h1">Transmission of IPv6 Packets over ITU-T G.9959 Networks</span>
Abstract
This document describes the frame format for transmission of IPv6
packets as well as a method of forming IPv6 link-local addresses and
statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks.
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="./rfc5741#section-2">Section 2 of RFC 5741</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/rfc7428">http://www.rfc-editor.org/info/rfc7428</a>.
Copyright Notice
Copyright (c) 2015 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">Brandt & Buron Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7428">RFC 7428</a> IPv6 over G.9959 February 2015</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Terms Used .................................................<a href="#page-3">3</a>
<a href="#section-1.2">1.2</a>. Requirements Language ......................................<a href="#page-4">4</a>
<a href="#section-2">2</a>. G.9959 Parameters to Use for IPv6 Transport .....................<a href="#page-5">5</a>
<a href="#section-2.1">2.1</a>. Addressing Mode ............................................<a href="#page-5">5</a>
<a href="#section-2.2">2.2</a>. IPv6 Multicast Support .....................................<a href="#page-6">6</a>
<a href="#section-2.3">2.3</a>. G.9959 MAC PDU Size and IPv6 MTU ...........................<a href="#page-6">6</a>
<a href="#section-2.4">2.4</a>. Transmission Status Indications ............................<a href="#page-7">7</a>
<a href="#section-2.5">2.5</a>. Transmission Security ......................................<a href="#page-7">7</a>
<a href="#section-3">3</a>. 6LoWPAN Adaptation Layer and Frame Format .......................<a href="#page-7">7</a>
<a href="#section-3.1">3.1</a>. Dispatch Header ............................................<a href="#page-8">8</a>
<a href="#section-4">4</a>. 6LoWPAN Addressing ..............................................<a href="#page-9">9</a>
4.1. Stateless Address Autoconfiguration of Routable IPv6
Addresses ..................................................<a href="#page-9">9</a>
<a href="#section-4.2">4.2</a>. IPv6 Link-Local Address ...................................<a href="#page-10">10</a>
<a href="#section-4.3">4.3</a>. Unicast Address Mapping ...................................<a href="#page-10">10</a>
<a href="#section-4.4">4.4</a>. On the Use of Neighbor Discovery Technologies .............<a href="#page-11">11</a>
<a href="#section-4.4.1">4.4.1</a>. Prefix and CID Management (Route-Over) .............<a href="#page-11">11</a>
<a href="#section-4.4.2">4.4.2</a>. Prefix and CID Management (Mesh-Under) .............<a href="#page-11">11</a>
<a href="#section-5">5</a>. Header Compression .............................................<a href="#page-12">12</a>
<a href="#section-6">6</a>. Security Considerations ........................................<a href="#page-13">13</a>
<a href="#section-7">7</a>. Privacy Considerations .........................................<a href="#page-14">14</a>
<a href="#section-8">8</a>. References .....................................................<a href="#page-14">14</a>
<a href="#section-8.1">8.1</a>. Normative References ......................................<a href="#page-14">14</a>
<a href="#section-8.2">8.2</a>. Informative References ....................................<a href="#page-16">16</a>
<a href="#appendix-A">Appendix A</a>. G.9959 6LoWPAN Datagram Example .......................<a href="#page-17">17</a>
Acknowledgements ..................................................<a href="#page-21">21</a>
Authors' Addresses ................................................<a href="#page-21">21</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The ITU-T G.9959 recommendation [<a href="#ref-G.9959" title=""Short range narrow-band digital radiocommunication transceivers - PHY and MAC layer specifications"">G.9959</a>] targets low-power Personal
Area Networks (PANs). This document defines the frame format for
transmission of IPv6 [<a href="./rfc2460" title=""Internet Protocol, Version 6 (IPv6) Specification"">RFC2460</a>] packets as well as the formation of
IPv6 link-local addresses and statelessly autoconfigured IPv6
addresses on G.9959 networks.
The general approach is to adapt elements of [<a href="./rfc4944" title=""Transmission of IPv6 Packets over IEEE 802.15.4 Networks"">RFC4944</a>] to G.9959
networks. G.9959 provides a Segmentation and Reassembly (SAR) layer
for transmission of datagrams larger than the G.9959 Media Access
Control Protocol Data Unit (MAC PDU).
[<a id="ref-RFC6775">RFC6775</a>] updates [<a href="./rfc4944" title=""Transmission of IPv6 Packets over IEEE 802.15.4 Networks"">RFC4944</a>] by specifying IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) optimizations for IPv6
Neighbor Discovery (ND) (originally defined by [<a href="./rfc4861" title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</a>]). This
document limits the use of [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>] to prefix and Context ID
<span class="grey">Brandt & Buron Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7428">RFC 7428</a> IPv6 over G.9959 February 2015</span>
assignment. An Interface Identifier (IID) may be constructed from a
G.9959 link-layer address, leading to a "link-layer-derived IPv6
address". If using that method, Duplicate Address Detection (DAD) is
not needed. Alternatively, IPv6 addresses may be assigned centrally
via DHCP, leading to a "non-link-layer-derived IPv6 address".
Address registration is only needed in certain cases.
In addition to IPv6 application communication, the frame format
defined in this document may be used by IPv6 routing protocols such
as the Routing Protocol for Low-Power and Lossy Networks (RPL)
[<a href="./rfc6550" title=""RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks"">RFC6550</a>] or Reactive Discovery of Point-to-Point Routes in Low-Power
and Lossy Networks (P2P-RPL) [<a href="./rfc6997" title=""Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks"">RFC6997</a>] to implement IPv6 routing over
G.9959 networks.
The encapsulation frame defined by this specification may optionally
be transported via mesh routing below the 6LoWPAN layer. Mesh-under
and route-over routing protocol specifications are out of scope for
this document.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terms Used</span>
6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network
ABR: Authoritative 6LoWPAN Border Router (Authoritative 6LBR)
[<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>]
Ack: Acknowledgement
AES: Advanced Encryption Standard
CID: Context Identifier [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>]
DAD: Duplicate Address Detection [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>]
DHCPv6: Dynamic Host Configuration Protocol for IPv6 [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>]
EUI-64: Extended Unique Identifier [<a href="#ref-EUI64" title=""Guidelines for 64-bit Global Identifier (EUI-64TM)"">EUI64</a>]
G.9959: Short range narrow-band digital radiocommunication
transceiver [<a href="#ref-G.9959" title=""Short range narrow-band digital radiocommunication transceivers - PHY and MAC layer specifications"">G.9959</a>]
GHC: Generic Header Compression [<a href="./rfc7400" title=""6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC7400</a>]
HomeID: G.9959 Link-Layer Network Identifier
IID: Interface Identifier
<span class="grey">Brandt & Buron Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7428">RFC 7428</a> IPv6 over G.9959 February 2015</span>
Link-layer-derived address: IPv6 address constructed on the basis of
link-layer address information
MAC: Media Access Control
Mesh-under: Forwarding via mesh routing below the 6LoWPAN layer
MTU: Maximum Transmission Unit
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>]
NodeID: G.9959 Link-Layer Node Identifier
Non-link-layer-derived address: IPv6 address assigned by a managed
process, e.g., DHCPv6
P2P-RPL: Reactive Discovery of Point-to-Point Routes in Low-Power and
Lossy Networks [<a href="./rfc6997" title=""Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks"">RFC6997</a>]
PAN: Personal Area Network
PDU: Protocol Data Unit
PHY: Physical Layer
RA: Router Advertisement [<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>]
Route-over: Forwarding via IP routing above the 6LoWPAN layer
RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks [<a href="./rfc6550" title=""RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks"">RFC6550</a>]
SAR: G.9959 Segmentation and Reassembly
ULA: Unique Local Address [<a href="./rfc4193" title=""Unique Local IPv6 Unicast Addresses"">RFC4193</a>]
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Requirements Language</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD 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="grey">Brandt & Buron Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7428">RFC 7428</a> IPv6 over G.9959 February 2015</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. G.9959 Parameters to Use for IPv6 Transport</span>
This section outlines properties applying to the PHY and MAC layers
of G.9959 and how to use these for IPv6 transport.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Addressing Mode</span>
G.9959 defines how a unique 32-bit HomeID network identifier is
assigned by a network controller and how an 8-bit NodeID host
identifier is allocated to each node. NodeIDs are unique within the
network identified by the HomeID. The G.9959 HomeID represents an
IPv6 subnet that is identified by one or more IPv6 prefixes.
An IPv6 host MUST construct its link-local IPv6 address from the
link-layer-derived IID in order to facilitate IP header compression
as described in [<a href="./rfc6282" title=""Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks"">RFC6282</a>].
A node interface MAY support the M flag of the RA message for the
construction of routable IPv6 addresses. A cost-optimized node
implementation may save memory by skipping support for the M flag.
The M flag MUST be interpreted as defined in Figure 1.
+--------+--------+---------------------------------------------+
| M flag | M flag | Required node behavior |
| support| value | |
+--------+--------+---------------------------------------------+
| No |(ignore)| Node MUST use link-layer-derived addressing |
+--------+--------+---------------------------------------------+
| Yes | 0 | Node MUST use link-layer-derived addressing |
| +--------+---------------------------------------------+
| | 1 | Node MUST use DHCPv6-based addressing, and |
| | | node MUST comply fully with [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>] |
+--------+--------+---------------------------------------------+
Figure 1: RA M Flag Support and Interpretation
A node that uses DHCPv6-based addressing MUST comply fully with the
text of [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>].
If DHCPv6-based addressing is used, the DHCPv6 client must use a
DHCPv6 Unique Identifier (DUID) of type DUID-UUID, as described in
[<a href="./rfc6355" title=""Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)"">RFC6355</a>]. The Universally Unique Identifier (UUID) used in the
DUID-UUID must be generated as specified in <a href="./rfc4122#section-4.5">[RFC4122], Section 4.5</a>,
starting at the third paragraph in that section (the 47-bit random
number-based UUID). The DUID must be stored persistently by the node
as specified in <a href="./rfc6355#section-3">Section 3 of [RFC6355]</a>.
<span class="grey">Brandt & Buron Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7428">RFC 7428</a> IPv6 over G.9959 February 2015</span>
A word of caution: since HomeIDs and NodeIDs are handed out by a
network controller function during inclusion, identifier validity and
uniqueness are limited by the lifetime of the network membership.
This can be cut short by a mishap occurring at the network
controller. Having a single point of failure at the network
controller suggests that high-reliability network deployments may
benefit from a redundant network controller function.
This warning applies to link-layer-derived addressing as well as to
non-link-layer-derived addressing deployments.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. IPv6 Multicast Support</span>
[<a id="ref-RFC3819">RFC3819</a>] recommends that IP subnetworks support (subnet-wide)
multicast. G.9959 supports direct-range IPv6 multicast, while
subnet-wide multicast is not supported natively by G.9959. Subnet-
wide multicast may be provided by an IP routing protocol or a mesh
routing protocol operating below the 6LoWPAN layer. Routing protocol
specifications are out of scope for this document.
IPv6 multicast packets MUST be carried via G.9959 broadcast.
As per [<a href="#ref-G.9959" title=""Short range narrow-band digital radiocommunication transceivers - PHY and MAC layer specifications"">G.9959</a>], this is accomplished as follows:
1. The destination HomeID of the G.9959 MAC PDU MUST be the HomeID
of the network.
2. The destination NodeID of the G.9959 MAC PDU MUST be the
broadcast NodeID (0xff).
G.9959 broadcast MAC PDUs are only intercepted by nodes within the
network identified by the HomeID.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. G.9959 MAC PDU Size and IPv6 MTU</span>
IPv6 packets MUST be transmitted using G.9959 transmission profile R3
or higher.
[<a id="ref-RFC2460">RFC2460</a>] specifies that any link that cannot convey a 1280-octet
packet in one piece must provide link-specific fragmentation and
reassembly at a layer below IPv6.
G.9959 provides segmentation and reassembly for payloads up to
1350 octets. IPv6 header compression [<a href="./rfc6282" title=""Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks"">RFC6282</a>] improves the chances
that a short IPv6 packet can fit into a single G.9959 frame.
Therefore, <a href="#section-3">Section 3</a> of this document specifies that [<a href="./rfc6282" title=""Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks"">RFC6282</a>] MUST
be supported. With the mandatory link-layer security enabled, a
G.9959 R3 MAC PDU may accommodate 6LoWPAN datagrams of up to
<span class="grey">Brandt & Buron Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7428">RFC 7428</a> IPv6 over G.9959 February 2015</span>
130 octets without triggering G.9959 segmentation and reassembly.
Longer 6LoWPAN datagrams will lead to the transmission of multiple
G.9959 PDUs.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Transmission Status Indications</span>
The G.9959 MAC layer provides native acknowledgement and
retransmission of MAC PDUs. The G.9959 SAR layer does the same for
larger datagrams. A mesh routing layer may provide a similar feature
for routed communication. An IPv6 routing stack communicating over
G.9959 may utilize link-layer status indications such as delivery
confirmation and Ack timeout from the MAC layer.
<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>. Transmission Security</span>
Implementations claiming conformance with this document MUST enable
G.9959 shared network key security.
The shared network key is intended to address security requirements
in the home at the normal level of security requirements. For
applications with high or very high requirements for confidentiality
and/or integrity, additional application-layer security measures for
end-to-end authentication and encryption may need to be applied.
(The availability of the network relies on the security properties of
the network key in any case.)
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. 6LoWPAN Adaptation Layer and Frame Format</span>
The 6LoWPAN encapsulation formats defined in this section are carried
as payload in the G.9959 MAC PDU. IPv6 header compression [<a href="./rfc6282" title=""Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks"">RFC6282</a>]
MUST be supported by implementations of this specification. Further,
implementations MAY support Generic Header Compression (GHC)
[<a href="./rfc7400" title=""6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC7400</a>]. A node implementing [<a href="./rfc7400" title=""6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC7400</a>] MUST probe its peers for
GHC support before applying GHC.
All 6LoWPAN datagrams transported over G.9959 are prefixed by a
6LoWPAN encapsulation header stack. The 6LoWPAN payload follows this
encapsulation header stack. Each header in the header stack contains
a header type followed by zero or more header fields. An IPv6 header
stack may contain, in the following order, addressing, hop-by-hop
options, routing, fragmentation, destination options, and, finally,
payload [<a href="./rfc2460" title=""Internet Protocol, Version 6 (IPv6) Specification"">RFC2460</a>]. The 6LoWPAN header format is structured the same
way. Currently, only one payload option is defined for the G.9959
6LoWPAN header format.
<span class="grey">Brandt & Buron Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7428">RFC 7428</a> IPv6 over G.9959 February 2015</span>
The definition of 6LoWPAN headers consists of the dispatch value, the
definition of the header fields that follow, and their ordering
constraints relative to all other headers. Although the header stack
structure provides a mechanism to address future demands on the
6LoWPAN adaptation layer, it is not intended to provide general-
purpose extensibility.
An example of a complete G.9959 6LoWPAN datagram can be found in
<a href="#appendix-A">Appendix A</a>.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Dispatch Header</span>
The Dispatch Header is shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6LoWPAN CmdCls| Dispatch | Type-specific header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Dispatch Type and Header
6LoWPAN CmdCls: 6LoWPAN Command Class identifier. This field MUST
carry the value 0x4F [<a href="#ref-G.9959" title=""Short range narrow-band digital radiocommunication transceivers - PHY and MAC layer specifications"">G.9959</a>]. The value is assigned by the ITU-T
and specifies that the following bits are a 6LoWPAN encapsulated
datagram. 6LoWPAN protocols MUST ignore the G.9959 frame if the
6LoWPAN Command Class identifier deviates from 0x4F.
Dispatch: Identifies the header type immediately following the
Dispatch Header.
Type-specific header: A header determined by the Dispatch Header.
The dispatch value may be treated as an unstructured namespace. Only
a few symbols are required to represent current 6LoWPAN
functionality. Although some additional savings could be achieved by
encoding additional functionality into the dispatch byte, these
measures would tend to constrain the ability to address future
alternatives.
<span class="grey">Brandt & Buron Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7428">RFC 7428</a> IPv6 over G.9959 February 2015</span>
+------------+--------------------+-----------+
| Pattern | Header Type | Reference |
+------------+--------------------+-----------+
| 01 1xxxxx | 6LoWPAN_IPHC | [<a href="./rfc6282" title=""Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks"">RFC6282</a>] |
+------------+--------------------+-----------+
Other IANA-assigned 6LoWPAN dispatch values do not
apply to this document.
Figure 3: Dispatch Values
6LoWPAN_IPHC: IPv6 Header Compression. Refer to [<a href="./rfc6282" title=""Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks"">RFC6282</a>].
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. 6LoWPAN Addressing</span>
IPv6 addresses may be autoconfigured from IIDs that may again be
constructed from link-layer address information to save memory in
devices and to facilitate efficient IP header compression as per
[<a href="./rfc6282" title=""Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks"">RFC6282</a>]. Link-layer-derived addresses have a static nature and may
involuntarily expose private usage data on public networks. Refer to
<a href="#section-7">Section 7</a>.
A NodeID is mapped into an IEEE EUI-64 identifier as follows:
IID = 0000:00ff:fe00:YYXX
Figure 4: Constructing a Compressible IID
where XX carries the G.9959 NodeID and YY is a 1-byte value chosen by
the individual node. The default YY value MUST be zero. A node MAY
use values of YY other than zero to form additional IIDs in order to
instantiate multiple IPv6 interfaces. The YY value MUST be ignored
when computing the corresponding NodeID (the XX value) from an IID.
The method of constructing IIDs from the link-layer address obviously
does not support addresses assigned or constructed by other means. A
node MUST NOT compute the NodeID from the IID if the first 6 bytes of
the IID do not comply with the format defined in Figure 4. In that
case, the address resolution mechanisms of [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>] apply.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Stateless Address Autoconfiguration of Routable IPv6 Addresses</span>
The IID defined above MUST be used whether autoconfiguring a ULA IPv6
address [<a href="./rfc4193" title=""Unique Local IPv6 Unicast Addresses"">RFC4193</a>] or a globally routable IPv6 address [<a href="./rfc3587" title=""IPv6 Global Unicast Address Format"">RFC3587</a>] in
G.9959 subnets.
<span class="grey">Brandt & Buron Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7428">RFC 7428</a> IPv6 over G.9959 February 2015</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. IPv6 Link-Local Address</span>
The IPv6 link-local address [<a href="./rfc4291" title=""IP Version 6 Addressing Architecture"">RFC4291</a>] for a G.9959 interface is
formed by appending the IID defined above to the IPv6 link-local
prefix fe80::/64.
The "Universal/Local" (U/L) bit MUST be set to zero in keeping with
the fact that this is not a globally unique value [<a href="#ref-EUI64" title=""Guidelines for 64-bit Global Identifier (EUI-64TM)"">EUI64</a>].
The resulting link-local address is formed as follows:
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier (IID) |
+----------+-----------------------+----------------------------+
Figure 5: IPv6 Link-Local Address
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Unicast Address Mapping</span>
The address resolution procedure for mapping IPv6 unicast addresses
into G.9959 link-layer addresses follows the general description in
<a href="./rfc4861#section-7.2">Section 7.2 of [RFC4861]</a>. The Source/Target Link-layer Address
option MUST have the following form when the link layer is G.9959.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | NodeID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding |
+- -+
| (All zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: IPv6 Unicast Address Mapping
Option fields:
Type: The value 1 signifies the Source Link-layer address. The
value 2 signifies the Destination Link-layer address.
Length: This is the length of this option (including the Type and
Length fields) in units of 8 octets. The value of this field is
always 1 for G.9959 NodeIDs.
<span class="grey">Brandt & Buron Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7428">RFC 7428</a> IPv6 over G.9959 February 2015</span>
NodeID: This is the G.9959 NodeID to which the actual interface
currently responds. The link-layer address may change if the
interface joins another network at a later time.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. On the Use of Neighbor Discovery Technologies</span>
[<a id="ref-RFC4861">RFC4861</a>] specifies how IPv6 nodes may resolve link-layer addresses
from IPv6 addresses via the use of link-local IPv6 multicast.
[<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>] is an optimization of [<a href="./rfc4861" title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</a>], specifically targeting
6LoWPAN networks. [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>] defines how a 6LoWPAN node may register
IPv6 addresses with an authoritative border router (ABR). Mesh-under
networks MUST NOT use [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>] address registration. However,
[<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>] address registration MUST be used if the first 6 bytes of
the IID do not comply with the format defined in Figure 4.
<span class="h4"><a class="selflink" id="section-4.4.1" href="#section-4.4.1">4.4.1</a>. Prefix and CID Management (Route-Over)</span>
In route-over environments, IPv6 hosts MUST use [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>] address
registration. A node implementation for route-over operation MAY use
[<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>] mechanisms for obtaining IPv6 prefixes and corresponding
header compression context information [<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>] route-
over requirements apply with no modifications.
<span class="h4"><a class="selflink" id="section-4.4.2" href="#section-4.4.2">4.4.2</a>. Prefix and CID Management (Mesh-Under)</span>
An implementation for mesh-under operation MUST use [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>]
mechanisms for managing IPv6 prefixes and corresponding header
compression context information [<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>] Duplicate
Address Detection (DAD) MUST NOT be used, since the link-layer
inclusion process of G.9959 ensures that a NodeID is unique for a
given HomeID.
With this exception and the specific redefinition of the RA Router
Lifetime value 0xFFFF (refer to <a href="#section-4.4.2.3">Section 4.4.2.3</a>), the text of the
following subsections is in compliance with [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>].
<span class="h5"><a class="selflink" id="section-4.4.2.1" href="#section-4.4.2.1">4.4.2.1</a>. Prefix Assignment Considerations</span>
As stated by [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>], an ABR is responsible for managing
prefix(es). Global routable prefixes may change over time. It is
RECOMMENDED that a ULA prefix is assigned to the 6LoWPAN subnet to
facilitate stable site-local application associations based on IPv6
addresses. A node MAY support the M flag of the RA message. This
influences the way IPv6 addresses are assigned. Refer to <a href="#section-2.1">Section 2.1</a>
for details.
<span class="grey">Brandt & Buron Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7428">RFC 7428</a> IPv6 over G.9959 February 2015</span>
<span class="h5"><a class="selflink" id="section-4.4.2.2" href="#section-4.4.2.2">4.4.2.2</a>. Robust and Efficient CID Management</span>
The 6LoWPAN Context Option (6CO) is used according to [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>] in an
RA to disseminate Context IDs (CIDs) to use for compressing prefixes.
One or more prefixes and corresponding Context IDs MUST be assigned
during initial node inclusion.
When updating context information, a CID may have its lifetime set to
zero to obsolete it. The CID MUST NOT be reused immediately; rather,
the next vacant CID should be assigned. Header compression based on
CIDs MUST NOT be used for RA messages carrying context information.
An expired CID and the associated prefix MUST NOT be reset but rather
must be retained in receive-only mode if there is no other current
need for the CID value. This will allow an ABR to detect if a
sleeping node without a clock uses an expired CID, and in response,
the ABR MUST return an RA with fresh context information to the
originator.
<span class="h5"><a class="selflink" id="section-4.4.2.3" href="#section-4.4.2.3">4.4.2.3</a>. Infinite Prefix Lifetime Support for Island-Mode Networks</span>
Nodes MUST renew the prefix and CID according to the lifetime
signaled by the ABR. [<a href="./rfc6775" title=""Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC6775</a>] specifies that the maximum value of
the RA Router Lifetime field MAY be up to 0xFFFF. This document
further specifies that the value 0xFFFF MUST be interpreted as
infinite lifetime. This value MUST NOT be used by ABRs. Its use is
only intended for a sleeping network controller -- for instance, a
battery-powered remote control being master for a small island-mode
network of light modules.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Header Compression</span>
IPv6 header compression [<a href="./rfc6282" title=""Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks"">RFC6282</a>] MUST be implemented, and GHC
[<a href="./rfc7400" title=""6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC7400</a>] compression for higher layers MAY be implemented. This
section will simply identify substitutions that should be made when
interpreting the text of [<a href="./rfc6282" title=""Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks"">RFC6282</a>] and [<a href="./rfc7400" title=""6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"">RFC7400</a>].
In general, the following substitutions should be made:
o Replace "802.15.4" with "G.9959".
o Replace "802.15.4 short address" with "<Interface><G.9959
NodeID>".
o Replace "802.15.4 PAN ID" with "G.9959 HomeID".
<span class="grey">Brandt & Buron Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7428">RFC 7428</a> IPv6 over G.9959 February 2015</span>
When a 16-bit address is called for (i.e., an IEEE 802.15.4 "short
address"), it MUST be formed by prepending an Interface label byte to
the G.9959 NodeID:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface | NodeID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A transmitting node may be sending to an IPv6 destination address
that can be reconstructed from the link-layer destination address.
If the Interface number is zero (the default value), all IPv6 address
bytes may be elided. Likewise, the Interface number of a fully
elided IPv6 address (i.e., SAM/DAM=11) may be reconstructed to the
value zero by a receiving node.
64-bit 802.15.4 address details do not apply.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
The method of derivation of Interface Identifiers from 8-bit NodeIDs
preserves uniqueness within the network. However, there is no
protection from duplication through forgery. Neighbor Discovery in
G.9959 links may be susceptible to threats as detailed in [<a href="./rfc3756" title=""IPv6 Neighbor Discovery (ND) Trust Models and Threats"">RFC3756</a>].
G.9959 networks may feature mesh routing. This implies additional
threats due to ad hoc routing as per [<a href="#ref-KW03" title=""Secure Routing in Sensor Networks: Attacks and Countermeasures"">KW03</a>]. G.9959 provides
capability for link-layer security. G.9959 nodes MUST use link-layer
security with a shared key. Doing so will alleviate the majority of
threats stated above. A sizable portion of G.9959 devices is
expected to always communicate within their PAN (i.e., within their
subnet, in IPv6 terms). In response to cost and power consumption
considerations, these devices will typically implement the minimum
set of features necessary. Accordingly, security for such devices
may rely on the mechanisms defined at the link layer by G.9959.
G.9959 relies on the Advanced Encryption Standard (AES) for
authentication and encryption of G.9959 frames and further employs
challenge-response handshaking to prevent replay attacks.
It is also expected that some G.9959 devices (e.g., billing and/or
safety-critical products) will implement coordination or integration
functions. These may communicate regularly with IPv6 peers outside
the subnet. Such IPv6 devices are expected to secure their end-to-
end communications with standard security mechanisms (e.g., IPsec,
Transport Layer Security (TLS), etc.).
<span class="grey">Brandt & Buron Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7428">RFC 7428</a> IPv6 over G.9959 February 2015</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Privacy Considerations</span>
IP addresses may be used to track devices on the Internet; such
devices can in turn be linked to individuals and their activities.
Depending on the application and the actual use pattern, this may be
undesirable. To impede tracking, globally unique and non-changing
characteristics of IP addresses should be avoided, e.g., by
frequently changing the global prefix and avoiding unique link-layer-
derived IIDs in addresses.
Some link layers use a 48-bit or 64-bit link-layer address that
uniquely identifies the node on a global scale, regardless of global
prefix changes. The risk of exposing a G.9959 device from its
link-layer-derived IID is limited because of the short 8-bit
link-layer address.
While intended for central address management, DHCPv6 address
assignment also decouples the IPv6 address from the link-layer
address. Addresses may be made dynamic by the use of a short DHCP
lease period and an assignment policy that makes the DHCP server hand
out a fresh IP address every time. For enhanced privacy, the
DHCP-assigned addresses should be logged only for the duration of the
lease, provided the implementation also allows logging for longer
durations as per the operational policies.
It should be noted that privacy and frequently changing address
assignments come at a cost. Non-link-layer-derived IIDs require the
use of address registration. Further, non-link-layer-derived IIDs
cannot be compressed; this leads to longer datagrams and increased
link-layer segmentation. Finally, frequent prefix changes
necessitate more Context Identifier updates; this not only leads to
increased traffic but also may affect the battery lifetime of
sleeping nodes.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-G.9959">G.9959</a>] International Telecommunication Union, "Short range
narrow-band digital radiocommunication transceivers - PHY
and MAC layer specifications", ITU-T Recommendation
G.9959, January 2015,
<<a href="http://www.itu.int/rec/T-REC-G.9959">http://www.itu.int/rec/T-REC-G.9959</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>, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
<span class="grey">Brandt & Buron Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7428">RFC 7428</a> IPv6 over G.9959 February 2015</span>
[<a id="ref-RFC2460">RFC2460</a>] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", <a href="./rfc2460">RFC 2460</a>, December 1998,
<<a href="http://www.rfc-editor.org/info/rfc2460">http://www.rfc-editor.org/info/rfc2460</a>>.
[<a id="ref-RFC4122">RFC4122</a>] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", <a href="./rfc4122">RFC 4122</a>,
July 2005, <<a href="http://www.rfc-editor.org/info/rfc4122">http://www.rfc-editor.org/info/rfc4122</a>>.
[<a id="ref-RFC4193">RFC4193</a>] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", <a href="./rfc4193">RFC 4193</a>, 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>, February 2006,
<<a href="http://www.rfc-editor.org/info/rfc4291">http://www.rfc-editor.org/info/rfc4291</a>>.
[<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>,
September 2007, <<a href="http://www.rfc-editor.org/info/rfc4861">http://www.rfc-editor.org/info/rfc4861</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>, 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. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", <a href="./rfc6282">RFC 6282</a>,
September 2011, <<a href="http://www.rfc-editor.org/info/rfc6282">http://www.rfc-editor.org/info/rfc6282</a>>.
[<a id="ref-RFC6355">RFC6355</a>] Narten, T. and J. Johnson, "Definition of the UUID-Based
DHCPv6 Unique Identifier (DUID-UUID)", <a href="./rfc6355">RFC 6355</a>,
August 2011, <<a href="http://www.rfc-editor.org/info/rfc6355">http://www.rfc-editor.org/info/rfc6355</a>>.
[<a id="ref-RFC6775">RFC6775</a>] Shelby, Z., 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>,
November 2012, <<a href="http://www.rfc-editor.org/info/rfc6775">http://www.rfc-editor.org/info/rfc6775</a>>.
[<a id="ref-RFC7400">RFC7400</a>] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs)", <a href="./rfc7400">RFC 7400</a>, November 2014,
<<a href="http://www.rfc-editor.org/info/rfc7400">http://www.rfc-editor.org/info/rfc7400</a>>.
<span class="grey">Brandt & Buron Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7428">RFC 7428</a> IPv6 over G.9959 February 2015</span>
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-EUI64">EUI64</a>] IEEE, "Guidelines for 64-bit Global Identifier
(EUI-64TM)", November 2012, <<a href="http://standards.ieee.org/regauth/oui/tutorials/EUI64.html">http://standards.ieee.org/</a>
<a href="http://standards.ieee.org/regauth/oui/tutorials/EUI64.html">regauth/oui/tutorials/EUI64.html</a>>.
[<a id="ref-KW03">KW03</a>] Karlof, C. and D. Wagner, "Secure Routing in Sensor
Networks: Attacks and Countermeasures", Elsevier Ad Hoc
Networks Journal, Special Issue on Sensor Network
Applications and Protocols, vol. 1, issues 2-3,
September 2003.
[<a id="ref-RFC3315">RFC3315</a>] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", <a href="./rfc3315">RFC 3315</a>, July 2003,
<<a href="http://www.rfc-editor.org/info/rfc3315">http://www.rfc-editor.org/info/rfc3315</a>>.
[<a id="ref-RFC3587">RFC3587</a>] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", <a href="./rfc3587">RFC 3587</a>, August 2003,
<<a href="http://www.rfc-editor.org/info/rfc3587">http://www.rfc-editor.org/info/rfc3587</a>>.
[<a id="ref-RFC3756">RFC3756</a>] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", <a href="./rfc3756">RFC 3756</a>,
May 2004, <<a href="http://www.rfc-editor.org/info/rfc3756">http://www.rfc-editor.org/info/rfc3756</a>>.
[<a id="ref-RFC3819">RFC3819</a>] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", <a href="https://www.rfc-editor.org/bcp/bcp89">BCP 89</a>,
<a href="./rfc3819">RFC 3819</a>, July 2004,
<<a href="http://www.rfc-editor.org/info/rfc3819">http://www.rfc-editor.org/info/rfc3819</a>>.
[<a id="ref-RFC6550">RFC6550</a>] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", <a href="./rfc6550">RFC 6550</a>, March 2012,
<<a href="http://www.rfc-editor.org/info/rfc6550">http://www.rfc-editor.org/info/rfc6550</a>>.
[<a id="ref-RFC6997">RFC6997</a>] Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J.
Martocci, "Reactive Discovery of Point-to-Point Routes in
Low-Power and Lossy Networks", <a href="./rfc6997">RFC 6997</a>, August 2013,
<<a href="http://www.rfc-editor.org/info/rfc6997">http://www.rfc-editor.org/info/rfc6997</a>>.
<span class="grey">Brandt & Buron Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc7428">RFC 7428</a> IPv6 over G.9959 February 2015</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. G.9959 6LoWPAN Datagram Example</span>
This example outlines each individual bit of a sample IPv6 UDP packet
arriving to a G.9959 node from a host in the Internet via a PAN
border router.
In the G.9959 PAN, the complete frame has the following fields.
G.9959:
+------+---------+----------+---+-----+----------...
|HomeID|SrcNodeID|FrmControl|Len|SeqNo|DestNodeID|
+------+---------+----------+---+-----+----------+-...
6LoWPAN:
...+--------------+----------------+-----------------------...
|6LoWPAN CmdCls|6LoWPAN_IPHC Hdr|Compressed IPv6 headers|
...-------------+----------------+-----------------------+-...
IPv6, TCP/UDP, App payload:
...+-------------------------+------------+-----------+
|Uncompressed IPv6 headers|TCP/UDP/ICMP|App payload|
...------------------------+------------+-----------+
The frame comes from the source IPv6 address
2001:0db8:ac10:ef01::ff:fe00:1206. The source prefix
2001:0db8:ac10:ef01/64 is identified by the IPHC CID = 3.
The frame is delivered in direct range from the gateway that has
source NodeID = 1. The Interface Identifier (IID) ff:fe00:1206 is
recognized as a link-layer-derived address and is compressed to the
16-bit value 0x1206.
The frame is sent to the destination IPv6 address
2001:0db8:27ef:42ca::ff:fe00:0004. The destination prefix
2001:0db8:27ef:42ca/64 is identified by the IPHC CID = 2.
The IID ff:fe00:0004 is recognized as a link-layer-derived address.
Thanks to the link-layer-derived addressing rules, the sender knows
that this is to be sent to G.9959 NodeID = 4, targeting the IPv6
interface instance number 0 (the default).
To reach the 6LoWPAN stack of the G.9959 node (skipping the G.9959
header fields), the first octet must be the 6LoWPAN Command Class
(0x4F).
<span class="grey">Brandt & Buron Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc7428">RFC 7428</a> IPv6 over G.9959 February 2015</span>
0
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-...
| 0x4F |
+-+-+-+-+-+-+-+-+-...
The Dispatch Header bits '011' advertise a compressed IPv6 header.
0 1
0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-...
| 0x4F |0 1 1
+-+-+-+-+-+-+-+-+-+-+-+-...
The following bits encode the first IPv6 header fields:
TF = '11' : Traffic Class and Flow Label are elided
NH = '1' : Next Header is elided
HLIM = '10' : Hop limit is 64
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x4F |0 1 1 1 1 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
CID = '1' : CI data follows the DAM field
SAC = '1' : Src addr uses stateful, context-based compression
SAM = '10' : Use src CID and 16 bits for link-layer-derived addr
M = '0' : Dest addr is not a multicast addr
DAC = '1' : Dest addr uses stateful, context-based compression
DAM = '11' : Use dest CID and dest NodeID to link-layer-derived addr
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x4F |0 1 1 1 1 1 1 0|1 1 1 0 0 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
<span class="grey">Brandt & Buron Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc7428">RFC 7428</a> IPv6 over G.9959 February 2015</span>
Address compression context identifiers:
SCI = 0x3
DCI = 0x2
2 3
4 5 6 7 8 9 0 1
...+-+-+-+-+-+-+-+-...
| 0x3 | 0x2 |
...+-+-+-+-+-+-+-+-...
IPv6 header fields:
(skipping "version" field)
(skipping "Traffic Class")
(skipping "flow label")
(skipping "payload length")
IPv6 header address fields:
SrcIP = 0x1206 : Use SCI and 16 least significant bits of
link-layer-derived address
(skipping DestIP ) - completely reconstructed from dest NodeID
and DCI
2 3 4
4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x3 | 0x2 | 0x12 | 0x06 |
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Next Header encoding for the UDP header:
Dispatch = '11110': Next Header dispatch code for UDP header
C = '0' : 16-bit checksum carried inline
P = '00' : Both src port and dest port are carried in-line
4 5
8 9 0 1 2 3 4 5
...+-+-+-+-+-+-+-+-...
|1 1 1 1 0|0|0 0|
...+-+-+-+-+-+-+-+-...
<span class="grey">Brandt & Buron Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc7428">RFC 7428</a> IPv6 over G.9959 February 2015</span>
UDP header fields:
src port = 0x1234
dest port = 0x5678
5 6 7 8
6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x12 | 0x34 | 0x56 | 0x78 |
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-..
(skipping "length")
checksum = .... (actual checksum value depends on
the actual UDP payload)
1
8 9 0
8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| (UDP checksum) |
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Add your own UDP payload here...
<span class="grey">Brandt & Buron Standards Track [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc7428">RFC 7428</a> IPv6 over G.9959 February 2015</span>
Acknowledgements
Thanks to the authors of <a href="./rfc4944">RFC 4944</a> and <a href="./rfc6282">RFC 6282</a>, and members of the
IETF 6LoWPAN working group; this document borrows extensively from
their work. Thanks to Erez Ben-Tovim, Erik Nordmark, Kerry Lynn,
Michael Richardson, and Tommas Jess Christensen for useful comments.
Thanks to Carsten Bormann for extensive feedback that improved this
document significantly. Thanks to Brian Haberman for pointing out
unclear details.
Authors' Addresses
Anders Brandt
Sigma Designs
Emdrupvej 26A, 1.
Copenhagen O 2100
Denmark
EMail: anders_brandt@sigmadesigns.com
Jakob Buron
Sigma Designs
Emdrupvej 26A, 1.
Copenhagen O 2100
Denmark
EMail: jakob_buron@sigmadesigns.com
Brandt & Buron Standards Track [Page 21]
</pre>
|
