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
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
|
<pre>Network Working Group S. Chakrabarti
Request for Comments: 4584 E. Nordmark
Category: Informational Sun Microsystems
July 2006
<span class="h1">Extension to Sockets API for Mobile IPv6</span>
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes data structures and API support for Mobile
IPv6 as an extension to the Advanced Socket API for IPv6.
Just as the Advanced Sockets API for IPv6 gives access to various
extension headers and the ICMPv6 protocol, this document specifies
the same level of access for Mobile IPv6 components. It specifies a
mechanism for applications to retrieve and set information for
Mobility Header messages, Home Address destination options, and
Routing Header Type 2 extension headers. It also specifies the
common data structures and definitions that might be used by certain
advanced Mobile IPv6 socket applications.
<span class="grey">Chakrabarti & Nordmark Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Applicability ...................................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Overview ........................................................<a href="#page-5">5</a>
<a href="#section-4">4</a>. Common Structures and Definitions ...............................<a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. The Mobility Header Data Structures ........................<a href="#page-6">6</a>
<a href="#section-4.1.1">4.1.1</a>. The ip6_mh Structure ................................<a href="#page-6">6</a>
<a href="#section-4.1.2">4.1.2</a>. Binding Refresh Request Mobility Message ............<a href="#page-7">7</a>
<a href="#section-4.1.3">4.1.3</a>. Home Address Test Init (HoTI) Message ...............<a href="#page-7">7</a>
<a href="#section-4.1.4">4.1.4</a>. Care-of Address Test Init (CoTI) Message ............<a href="#page-7">7</a>
<a href="#section-4.1.5">4.1.5</a>. Home Address Test (HOT) Message .....................<a href="#page-8">8</a>
<a href="#section-4.1.6">4.1.6</a>. Care Of Address Test (COT) Message ..................<a href="#page-8">8</a>
<a href="#section-4.1.7">4.1.7</a>. Binding Update Mobility Message .....................<a href="#page-8">8</a>
<a href="#section-4.1.8">4.1.8</a>. Binding Acknowledgement Mobility Message ............<a href="#page-9">9</a>
<a href="#section-4.1.9">4.1.9</a>. Binding Error Mobility Message ......................<a href="#page-9">9</a>
<a href="#section-4.1.10">4.1.10</a>. Mobility Option TLV data structure .................<a href="#page-9">9</a>
<a href="#section-4.1.11">4.1.11</a>. Mobility Option Data Structures ...................<a href="#page-10">10</a>
<a href="#section-4.1.11.1">4.1.11.1</a>. Binding Refresh Advice ...................<a href="#page-10">10</a>
<a href="#section-4.1.11.2">4.1.11.2</a>. Alternate Care-of Address ................<a href="#page-10">10</a>
<a href="#section-4.1.11.3">4.1.11.3</a>. Nonce Indices ............................<a href="#page-10">10</a>
<a href="#section-4.1.11.4">4.1.11.4</a>. Binding Authorization Data ...............<a href="#page-10">10</a>
<a href="#section-4.2">4.2</a>. Mobility Header Constants .................................<a href="#page-10">10</a>
<a href="#section-4.3">4.3</a>. IPv6 Home Address Destination Option ......................<a href="#page-12">12</a>
<a href="#section-4.4">4.4</a>. Type 2 Routing Header .....................................<a href="#page-12">12</a>
<a href="#section-4.5">4.5</a>. New ICMP Messages for Mobile IPv6 .........................<a href="#page-13">13</a>
<a href="#section-4.6">4.6</a>. IPv6 Neighbor Discovery Changes ...........................<a href="#page-14">14</a>
<a href="#section-5">5</a>. Access to Home Address Destination Option and Routing Headers ..15
<a href="#section-5.1">5.1</a>. Routing Header Access Functions ...........................<a href="#page-17">17</a>
<a href="#section-5.2">5.2</a>. Content of Type 2 Routing Header ..........................<a href="#page-18">18</a>
5.3. Order of Extension Headers for Home Address
Destination Options .......................................<a href="#page-19">19</a>
<a href="#section-5.4">5.4</a>. Home Address Destination Option Access Functions ..........<a href="#page-20">20</a>
<a href="#section-5.5">5.5</a>. Content of Home Address Destination Option ................<a href="#page-20">20</a>
<a href="#section-6">6</a>. Mobility Protocol Headers ......................................<a href="#page-21">21</a>
<a href="#section-6.1">6.1</a>. Receiving and Sending Mobility Header Messages ............<a href="#page-21">21</a>
<a href="#section-7">7</a>. Protocols File .................................................<a href="#page-22">22</a>
<a href="#section-8">8</a>. IPv4-Mapped IPv6 Addresses .....................................<a href="#page-23">23</a>
<a href="#section-9">9</a>. Security Considerations ........................................<a href="#page-23">23</a>
<a href="#section-10">10</a>. IANA Considerations ...........................................<a href="#page-23">23</a>
<a href="#section-11">11</a>. Acknowledgements ..............................................<a href="#page-23">23</a>
<a href="#section-12">12</a>. References ....................................................<a href="#page-24">24</a>
<a href="#section-12.1">12.1</a>. Normative References .....................................<a href="#page-24">24</a>
<a href="#section-12.2">12.2</a>. Informative References ...................................<a href="#page-24">24</a>
<span class="grey">Chakrabarti & Nordmark Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Mobility Support in IPv6 [<a href="#ref-2" title=""Mobility Support in IPv6"">2</a>] defines a new Mobility Protocol header,
a Home Address destination option and a new Routing Header type. It
is expected that Mobile IPv6 user-level implementations and some
special applications will need to access and process these IPv6
extension headers. This document is an extension to the existing
Advanced Sockets API document [<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>]; it addresses the Advanced IPv6
Sockets API for these new protocol elements defined by Mobile IPv6.
The applicability of this API mainly targets user-level applications.
However, it has also been shown to be useful within some Mobile IPv6
implementations; for instance, where part of the Mobile IPv6 protocol
is implemented at user-level and part in the kernel. It is up to any
such implementations to architect which part of the Mobile IPv6 and
IP Security (IPSec) packet processing should be done at the user-
level in order to meet the design needs of the particular platform
and operating system.
The target user-level applications for this socket API are believed
to be debugging and diagnostic applications and some policy
applications that would like to receive copies of protocol
information at the application layer.
The packet information and access to the extension headers (Routing
header and Destination options) are specified using the "ancillary
data" fields that were added to the 4.3BSD Reno sockets API in 1990.
The reason is that these ancillary data fields are part of the
Posix.1g standard and should therefore be adopted by most vendors.
This document is consistent with Advanced Sockets API for IPv6 [<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>] in
structure definitions, header files, and function definitions. Thus,
the implementors of this API document are assumed to be familiar with
the data structures, data sending and receiving procedures, and the
IPv6 extension header access functions described in the Advanced
Sockets API for IPv6 [<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>].
Non-goals
This document does not address application access to either the
Authentication Header or the Encapsulating Security Payload header.
This document also does not address any API that might be necessary
for Mobile Network [<a href="#ref-4" title=""Network Mobility (NEMO) Basic Support Protocol"">4</a>] specific needs. Furthermore, note that this
API document excludes discussion on application-level API. It
assumes that address selection socket API [<a href="#ref-5" title=""IPv6 Socket API for source address selection"">5</a>] takes care of selection
of care-of address or home address as the source address by the
application, when source address selection is required due to the
nature of the application.
<span class="grey">Chakrabarti & Nordmark Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
Providing mobility "awareness" to applications, such as applications'
being able to tell whether the host is at home or not, is out of
scope for this API.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Applicability</span>
This API document can be applied in the following cases:
1. User-level debugging and monitoring tools: This socket API is
useful for accessing Mobility Headers, Home Address destination
options and Type 2 Routing Headers . For example, mh-ping might
be a monitoring tool that can process mobility headers on the
receiving side to check binding status.
2. Partial user-level implementation of Mobile IPv6: We assume that
some implementations may choose to do the Mobility header
processing at user level. In that case, this document recommends
implementing at least the handling of Home Address destination
options and Type 2 Routing Header in the main IP processing paths
in the kernel. The API can then be used to send and receive the
Mobility Header packets used for Mobile IPv6 signaling.
3. Complete header processing at the kernel-level: Many
implementations of Mobile IPv6 [<a href="#ref-2" title=""Mobility Support in IPv6"">2</a>] perform processing of Home
Address destination options, Type 2 Routing Headers, and Mobility
headers at the kernel level. However, the kernel keeps a copy of
the received extension headers and passes them up to the API,
which is used by the user-level applications purely for
monitoring and debugging Mobile IPv6 packets.
On an IPv6 host that does not implement Mobile IPv6, the IPv6
specification [<a href="#ref-3" title=""Internet Protocol, Version 6 (IPv6) Specification"">3</a>] requires that packets with the Home Address option
or Type 2 Routing Header (where segments left is non-zero) be dropped
on receipt. This means that it is not possible to implement Mobile
IPv6 as an application on such a system. Thus, on such a system, the
applicability of this API is limited to the first case above,
enabling debugging and monitoring applications (such as tcpdump) to
parse and interpret Mobile IPv6 packets.
<span class="grey">Chakrabarti & Nordmark Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Overview</span>
This document can be divided into the following parts:
1. Definitions of constants and structures for C programs that
capture the Mobile IPv6 packet formats on the wire. A common
definition of these is useful at least for packet snooping
applications. This is captured in <a href="#section-4">Section 4</a>. In addition,
<a href="#section-4">Section 4</a> also defines data structures for Home Address
destination option, Type 2 Routing Header, and new ICMPv6
messages related to Mobile IPv6.
2. Notes on how to use the IPv6 Advanced API to access Home Address
options and Type 2 Routing Headers. This is captured in <a href="#section-5">Section</a>
<a href="#section-5">5</a>.
3. Notes on how user-level applications can observe MH (Mobility
Header) packets using raw sockets (in <a href="#section-6">Section 6</a>). The IPv6 RAW
socket interface described in this document allows applications
to receive MH packets whether or not the system's MH processing
takes place in the "kernel" or at the "user space".
4. A name is suggested for IPv6 Mobility Header protocol in /etc/
protocols (in <a href="#section-7">Section 7</a>).
All examples in this document omit error checking in favor of
brevity, as it is following the same style as the Advanced Socket API
[<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>].
Note that many of the functions and socket options defined in this
document may have error returns that are not defined in this
document.
Data types in this document follow the Posix.1g format: intN_t means
a signed integer of exactly N bits (e.g., int16_t), and uintN_t means
an unsigned integer of exactly N bits (e.g., uint32_t).
Once the API specification becomes mature and is deployed, it may be
formally standardized by a more appropriate body, as has been done
with the Basic API [<a href="#ref-6" title=""Basic Socket Interface Extensions for IPv6"">6</a>]. However, since this specification largely
builds upon the Advanced Socket API [<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>], such standardization would
make sense only if the Advanced Socket API [<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>] were also
standardized.
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">RFC 2119</a>.
<span class="grey">Chakrabarti & Nordmark Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Common Structures and Definitions</span>
In this section, the structures are specified in a way so that they
maximize the probability that the compiler-layout of data structures
are identical to the packet formats on the wire. However, ANSI-C
provides few guarantees about the size and alignment of data
structures.
The assumption is that the Advanced Socket API [<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>] will pass up the
actual packet content (the wire format) in the buffer and in the
ancillary data objects. Thus, if an implementor has to handle a
system where the ANSI-C compiler does not and can not lay out these
structures to match the wire formats in <a href="./rfc3775">RFC 3775</a> [<a href="#ref-2" title=""Mobility Support in IPv6"">2</a>], the structures
defined by this API can not be supported on such a system.
The constants and structures shown below are in network byte order,
so an application needs to perform the appropriate byte order
conversion (ntohs(), etc) when necessary.
The structures and constants below will be included when the (new)
header file is included : <netinet/ip6mh.h>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. The Mobility Header Data Structures</span>
<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>. The ip6_mh Structure</span>
The following structure is defined as a result of including
<netinet/ip6mh.h>. This is the fixed part of the Mobility Header.
Different Mobility message types are defined in Mobile IPv6 [<a href="#ref-2" title=""Mobility Support in IPv6"">2</a>]. For
portability and alignment reasons, each mobility message type
includes the mobility header fields instead of including the ip6_mh
structure, followed by the message-specific fields.
struct ip6_mh {
uint8_t ip6mh_proto; /* NO_NXTHDR by default */
uint8_t ip6mh_hdrlen; /* Header Len in unit of 8 Octets
excluding the first 8 Octets */
uint8_t ip6mh_type; /* Type of Mobility Header */
uint8_t ip6mh_reserved; /* Reserved */
uint16_t ip6mh_cksum; /* Mobility Header Checksum */
/* Followed by type specific messages */
};
<span class="grey">Chakrabarti & Nordmark Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>. Binding Refresh Request Mobility Message</span>
struct ip6_mh_binding_request {
uint8_t ip6mhbr_proto;
uint8_t ip6mhbr_hdrlen;
uint8_t ip6mhbr_type;
uint8_t ip6mhbr_reserved;
uint16_t ip6mhbr_cksum;
uint16_t ip6mhbr_reserved2;
/* Followed by optional Mobility Options */
};
<span class="h4"><a class="selflink" id="section-4.1.3" href="#section-4.1.3">4.1.3</a>. Home Address Test Init (HoTI) Message</span>
struct ip6_mh_home_test_init {
uint8_t ip6mhhti_proto;
uint8_t ip6mhhti_hdrlen;
uint8_t ip6mhhti_type;
uint8_t ip6mhhti_reserved;
uint16_t ip6mhhti_cksum;
uint16_t ip6mhhti_reserved2;
uint32_t ip6mhhti_cookie[2]; /* 64 bit Cookie by MN */
/* Followed by optional Mobility Options */
};
<span class="h4"><a class="selflink" id="section-4.1.4" href="#section-4.1.4">4.1.4</a>. Care-of Address Test Init (CoTI) Message</span>
struct ip6_mh_careof_test_init {
uint8_t ip6mhcti_proto;
uint8_t ip6mhcti_hdrlen;
uint8_t ip6mhcti_type;
uint8_t ip6mhcti_reserved;
uint16_t ip6mhcti_cksum;
uint16_t ip6mhcti_reserved2;
uint32_t ip6mhcti_cookie[2]; /* 64 bit Cookie by MN */
/* Followed by optional Mobility Options */
};
<span class="grey">Chakrabarti & Nordmark Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
<span class="h4"><a class="selflink" id="section-4.1.5" href="#section-4.1.5">4.1.5</a>. Home Address Test (HOT) Message</span>
struct ip6_mh_home_test {
uint8_t ip6mhht_proto;
uint8_t ip6mhht_hdrlen;
uint8_t ip6mhht_type;
uint8_t ip6mhht_reserved;
uint16_t ip6mhht_cksum;
uint16_t ip6mhht_nonce_index;
uint32_t ip6mhht_cookie[2]; /* Cookie from HOTI msg */
uint32_t ip6mhht_keygen[2]; /* 64 Bit Key by CN */
/* Followed by optional Mobility Options */
};
<span class="h4"><a class="selflink" id="section-4.1.6" href="#section-4.1.6">4.1.6</a>. Care Of Address Test (COT) Message</span>
struct ip6_mh_careof_test {
uint8_t ip6mhct_proto;
uint8_t ip6mhct_hdrlen;
uint8_t ip6mhct_type;
uint8_t ip6mhct_reserved;
uint16_t ip6mhct_cksum;
uint16_t ip6mhct_nonce_index;
uint32_t ip6mhct_cookie[2]; /* Cookie from COTI message */
uint32_t ip6mhct_keygen[2]; /* 64bit key by CN */
/* Followed by optional Mobility Options */
};
<span class="h4"><a class="selflink" id="section-4.1.7" href="#section-4.1.7">4.1.7</a>. Binding Update Mobility Message</span>
struct ip6_mh_binding_update {
uint8_t ip6mhbu_proto;
uint8_t ip6mhbu_hdrlen;
uint8_t ip6mhbu_type;
uint8_t ip6mhbu_reserved;
uint16_t ip6mhbu_cksum;
uint16_t ip6mhbu_seqno; /* Sequence Number */
uint16_t ip6mhbu_flags;
uint16_t ip6mhbu_lifetime; /* Time in unit of 4 sec */
/* Followed by optional Mobility Options */
};
/* Binding Update Flags, in network byte-order */
#define IP6_MH_BU_ACK 0x8000 /* Request a binding ack */
#define IP6_MH_BU_HOME 0x4000 /* Home Registration */
#define IP6_MH_BU_LLOCAL 0x2000 /* Link-local compatibility */
#define IP6_MH_BU_KEYM 0x1000 /* Key management mobility */
<span class="grey">Chakrabarti & Nordmark Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
<span class="h4"><a class="selflink" id="section-4.1.8" href="#section-4.1.8">4.1.8</a>. Binding Acknowledgement Mobility Message</span>
struct ip6_mh_binding_ack {
uint8_t ip6mhba_proto;
uint8_t ip6mhba_hdrlen;
uint8_t ip6mhba_type;
uint8_t ip6mhba_reserved;
uint16_t ip6mhba_cksum;
uint8_t ip6mhba_status; /* Status code */
uint8_t ip6mhba_flags;
uint16_t ip6mhba_seqno;
uint16_t ip6mhba_lifetime;
/* Followed by optional Mobility Options */
};
/* Binding Acknowledgement Flags */
#define IP6_MH_BA_KEYM 0x80 /* Key management mobility */
<span class="h4"><a class="selflink" id="section-4.1.9" href="#section-4.1.9">4.1.9</a>. Binding Error Mobility Message</span>
struct ip6_mh_binding_error {
uint8_t ip6mhbe_proto;
uint8_t ip6mhbe_hdrlen;
uint8_t ip6mhbe_type;
uint8_t ip6mhbe_reserved;
uint16_t ip6mhbe_cksum;
uint8_t ip6mhbe_status; /* Error Status */
uint8_t ip6mhbe_reserved2;
struct in6_addr ip6mhbe_homeaddr;
/* Followed by optional Mobility Options */
};
<span class="h4"><a class="selflink" id="section-4.1.10" href="#section-4.1.10">4.1.10</a>. Mobility Option TLV data structure</span>
struct ip6_mh_opt {
uint8_t ip6mhopt_type; /* Option Type */
uint8_t ip6mhopt_len; /* Option Length */
/* Followed by variable length Option Data in bytes */
};
<span class="grey">Chakrabarti & Nordmark Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
<span class="h4"><a class="selflink" id="section-4.1.11" href="#section-4.1.11">4.1.11</a>. Mobility Option Data Structures</span>
<span class="h5"><a class="selflink" id="section-4.1.11.1" href="#section-4.1.11.1">4.1.11.1</a>. Binding Refresh Advice</span>
struct ip6_mh_opt_refresh_advice {
uint8_t ip6mora_type;
uint8_t ip6mora_len;
uint16_t ip6mora_interval; /* Refresh interval in 4 sec */
};
<span class="h5"><a class="selflink" id="section-4.1.11.2" href="#section-4.1.11.2">4.1.11.2</a>. Alternate Care-of Address</span>
struct ip6_mh_opt_altcoa {
uint8_t ip6moa_type;
uint8_t ip6moa_len;
struct in6_addr ip6moa_addr; /* Alternate CoA */
};
<span class="h5"><a class="selflink" id="section-4.1.11.3" href="#section-4.1.11.3">4.1.11.3</a>. Nonce Indices</span>
struct ip6_mh_opt_nonce_index {
uint8_t ip6moni_type;
uint8_t ip6moni_len;
uint16_t ip6moni_home_nonce;
uint16_t ip6moni_coa_nonce;
};
<span class="h5"><a class="selflink" id="section-4.1.11.4" href="#section-4.1.11.4">4.1.11.4</a>. Binding Authorization Data</span>
struct ip6_mh_opt_auth_data {
uint8_t ip6moad_type;
uint8_t ip6moad_len;
uint8_t ip6moad_data[12];
};
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Mobility Header Constants</span>
IPv6 Next Header Value for Mobility:
<netinet/in.h>
#define IPPROTO_MH 135 /* IPv6 Mobility Header: IANA */
<span class="grey">Chakrabarti & Nordmark Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
Mobility Header Message Types:
<netinet/ip6mh.h>
#define IP6_MH_TYPE_BRR 0 /* Binding Refresh Request */
#define IP6_MH_TYPE_HOTI 1 /* HOTI Message */
#define IP6_MH_TYPE_COTI 2 /* COTI Message */
#define IP6_MH_TYPE_HOT 3 /* HOT Message */
#define IP6_MH_TYPE_COT 4 /* COT Message */
#define IP6_MH_TYPE_BU 5 /* Binding Update */
#define IP6_MH_TYPE_BACK 6 /* Binding ACK */
#define IP6_MH_TYPE_BERROR 7 /* Binding Error */
Mobility Header Message Option Types:
<netinet/ip6mh.h>
#define IP6_MHOPT_PAD1 0x00 /* PAD1 */
#define IP6_MHOPT_PADN 0x01 /* PADN */
#define IP6_MHOPT_BREFRESH 0x02 /* Binding Refresh */
#define IP6_MHOPT_ALTCOA 0x03 /* Alternate COA */
#define IP6_MHOPT_NONCEID 0x04 /* Nonce Index */
#define IP6_MHOPT_BAUTH 0x05 /* Binding Auth Data */
Status values accompanied with Mobility Binding Acknowledgement:
<netinet/ip6mh.h>
#define IP6_MH_BAS_ACCEPTED 0 /* BU accepted */
#define IP6_MH_BAS_PRFX_DISCOV 1 /* Accepted, but prefix
discovery Required */
#define IP6_MH_BAS_UNSPECIFIED 128 /* Reason unspecified */
#define IP6_MH_BAS_PROHIBIT 129 /* Administratively
prohibited */
#define IP6_MH_BAS_INSUFFICIENT 130 /* Insufficient
resources */
#define IP6_MH_BAS_HA_NOT_SUPPORTED 131 /* HA registration not
supported */
#define IP6_MH_BAS_NOT_HOME_SUBNET 132 /* Not Home subnet */
#define IP6_MH_BAS_NOT_HA 133 /* Not HA for this
mobile node */
#define IP6_MH_BAS_DAD_FAILED 134 /* DAD failed */
#define IP6_MH_BAS_SEQNO_BAD 135 /* Sequence number out
of range */
<span class="grey">Chakrabarti & Nordmark Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
#define IP6_MH_BAS_HOME_NI_EXPIRED 136 /* Expired Home nonce
index */
#define IP6_MH_BAS_COA_NI_EXPIRED 137 /* Expired Care-of
nonce index */
#define IP6_MH_BAS_NI_EXPIRED 138 /* Expired Nonce
Indices */
#define IP6_MH_BAS_REG_NOT_ALLOWED 139 /* Registration type
change disallowed */
Status values for the Binding Error mobility messages:
<netinet/ip6mh.h>
#define IP6_MH_BES_UNKNOWN_HAO 1 /* Unknown binding for HOA */
#define IP6_MH_BES_UNKNOWN_MH 2 /* Unknown MH Type */
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. IPv6 Home Address Destination Option</span>
Due to alignment issues in the compiler, and the alignment
requirements for this option, the included IPv6 address must be
specified as an array of 16 octets.
<netinet/ip6.h>
/* Home Address Destination Option */
struct ip6_opt_home_address {
uint8_t ip6oha_type;
uint8_t ip6oha_len;
uint8_t ip6oha_addr[16]; /* Home Address */
};
Option Type Definition:
#define IP6OPT_HOME_ADDRESS 0xc9 /* 11 0 01001 */
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Type 2 Routing Header</span>
<netinet/ip6.h>
/* Type 2 Routing header for Mobile IPv6 */
struct ip6_rthdr2 {
uint8_t ip6r2_nxt; /* next header */
uint8_t ip6r2_len; /* length : always 2 */
uint8_t ip6r2_type; /* always 2 */
uint8_t ip6r2_segleft; /* segments left: always 1 */
uint32_t ip6r2_reserved; /* reserved field */
struct in6_addr ip6r2_homeaddr; /* Home Address */
};
<span class="grey">Chakrabarti & Nordmark Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. New ICMP Messages for Mobile IPv6</span>
ICMP message types and definitions for Mobile IPv6 are defined in
<netinet/icmp6.h>.
#define MIP6_HA_DISCOVERY_REQUEST 144
#define MIP6_HA_DISCOVERY_REPLY 145
#define MIP6_PREFIX_SOLICIT 146
#define MIP6_PREFIX_ADVERT 147
The following data structures can be used for the ICMP message types
discussed in Sections <a href="#section-6.5">6.5</a> through <a href="#section-6.8">6.8</a> in the base Mobile IPv6 [<a href="#ref-2" title=""Mobility Support in IPv6"">2</a>]
specification.
struct mip6_dhaad_req { /* Dynamic HA Address Discovery */
struct icmp6_hdr mip6_dhreq_hdr;
};
#define mip6_dhreq_type mip6_dhreq_hdr.icmp6_type
#define mip6_dhreq_code mip6_dhreq_hdr.icmp6_code
#define mip6_dhreq_cksum mip6_dhreq_hdr.icmp6_cksum
#define mip6_dhreq_id mip6_dhreq_hdr.icmp6_data16[0]
#define mip6_dhreq_reserved mip6_dhreq_hdr.icmp6_data16[1]
struct mip6_dhaad_rep { /* HA Address Discovery Reply */
struct icmp6_hdr mip6_dhrep_hdr;
/* Followed by Home Agent IPv6 addresses */
};
#define mip6_dhrep_type mip6_dhrep_hdr.icmp6_type
#define mip6_dhrep_code mip6_dhrep_hdr.icmp6_code
#define mip6_dhrep_cksum mip6_dhrep_hdr.icmp6_cksum
#define mip6_dhrep_id mip6_dhrep_hdr.icmp6_data16[0]
#define mip6_dhrep_reserved mip6_dhrep_hdr.icmp6_data16[1]
struct mip6_prefix_solicit { /* Mobile Prefix Solicitation */
struct icmp6_hdr mip6_ps_hdr;
};
#define mip6_ps_type mip6_ps_hdr.icmp6_type
#define mip6_ps_code mip6_ps_hdr.icmp6_code
#define mip6_ps_cksum mip6_ps_hdr.icmp6_cksum
#define mip6_ps_id mip6_ps_hdr.icmp6_data16[0]
#define mip6_ps_reserved mip6_ps_hdr.icmp6_data16[1]
<span class="grey">Chakrabarti & Nordmark Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
struct mip6_prefix_advert { /* Mobile Prefix Advertisements */
struct icmp6_hdr mip6_pa_hdr;
/* Followed by one or more PI options */
};
#define mip6_pa_type mip6_pa_hdr.icmp6_type
#define mip6_pa_code mip6_pa_hdr.icmp6_code
#define mip6_pa_cksum mip6_pa_hdr.icmp6_cksum
#define mip6_pa_id mip6_pa_hdr.icmp6_data16[0]
#define mip6_pa_flags_reserved mip6_pa_hdr.icmp6_data16[1]
/* Mobile Prefix Advertisement Flags in network-byte order */
#define MIP6_PA_FLAG_MANAGED 0x8000
#define MIP6_PA_FLAG_OTHER 0x4000
Prefix options are defined in IPv6 Advanced Socket API [<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>]. The
Mobile IPv6 Base specification [<a href="#ref-2" title=""Mobility Support in IPv6"">2</a>] describes the modified behavior in
the 'Modifications to IPv6 Neighbor Discovery' section. Prefix
Options for Mobile IP are defined in the following section.
<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>. IPv6 Neighbor Discovery Changes</span>
IPv6 Neighbor Discovery changes are also defined in
<netinet/icmp6.h>.
New 'Home Agent' flag in router advertisement: #define
ND_RA_FLAG_HOMEAGENT 0x20 /* Home Agent flag in RA */
New Router flag with prefix information of the home agent:
#define ND_OPT_PI_FLAG_ROUTER 0x20 /* Router flag in PI */
As per the Mobile IPv6 specification [<a href="#ref-2" title=""Mobility Support in IPv6"">2</a>], Section 7.2, a Home Agent
MUST include at least one prefix option with the Router Address (R)
bit set. Advanced Socket API [<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>] defines data structure for prefix
option as follows:
struct nd_opt_prefix_info { /* prefix information */
uint8_t nd_opt_pi_type;
uint8_t nd_opt_pi_len;
uint8_t nd_opt_pi_prefix_len;
uint8_t nd_opt_pi_flags_reserved;
uint32_t nd_opt_pi_valid_time;
uint32_t nd_opt_pi_preferred_time;
uint32_t nd_opt_pi_reserved2;
struct in6_addr nd_opt_pi_prefix;
};
<span class="grey">Chakrabarti & Nordmark Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
New advertisement interval option and home agent information options
are defined in Mobile IPv6 [<a href="#ref-2" title=""Mobility Support in IPv6"">2</a>] base specification.
struct nd_opt_adv_interval { /* Advertisement interval option */
uint8_t nd_opt_ai_type;
uint8_t nd_opt_ai_len;
uint16_t nd_opt_ai_reserved;
uint32_t nd_opt_ai_interval;
};
The option types for the new Mobile IPv6 specific options:
#define ND_OPT_ADV_INTERVAL 7 /* Adv Interval Option */
#define ND_OPT_HA_INFORMATION 8 /* HA Information option */
struct nd_opt_homeagent_info { /* Home Agent information */
uint8_t nd_opt_hai_type;
uint8_t nd_opt_hai_len;
uint16_t nd_opt_hai_reserved;
uint16_t nd_opt_hai_preference;
uint16_t nd_opt_hai_lifetime;
};
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Access to Home Address Destination Option and Routing Headers</span>
Applications that need to be able to access Home Address destination
option and Type 2 Routing Header information can do so by setting the
appropriate setsockopt option and using ancillary data objects. The
order of extension headers is defined in Mobile IPv6 [<a href="#ref-2" title=""Mobility Support in IPv6"">2</a>] when an IPv6
packet with a Home Address Destination Option is sent with other
possible extension headers. <a href="#section-5.3">Section 5.3</a> elaborates on the extension
header order when all possible cases are present.
This document does not recommend that the user-level program set the
Home Address destination option or Type 2 Routing Header option;
however, for clarity it defines the order of extension headers. See
<a href="#section-2">Section 2</a> of this document for appropriate usage of sending and
receiving of Home Address destination options and Type 2 Routing
Header extension headers.
This document defines a new socket option, IPV6_MIPDSTOPTS for
sending Home Address destination options. In order to receive a Home
Address destination option or Type 2 Route Header, applications must
call setsockopt() to turn on the corresponding flag as described in
IPv6 Advanced Socket API [<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>] ( for brevity, error checking is not
performed in the examples):
<span class="grey">Chakrabarti & Nordmark Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS,
&on, sizeof(on));
When any of these options are enabled, the corresponding data is
returned as control information by recvmsg(), as one or more
ancillary data objects. Receiving the above information for TCP
applications is not defined in this document (see <a href="#section-4.1">Section 4.1</a> of
Advanced Sockets API for IPv6 [<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>]).
Note that if the IP implementation on the host does not implement the
handling of Type 2 Routing Headers or Home Address options, per <a href="./rfc2460">RFC</a>
<a href="./rfc2460">2460</a> [<a href="#ref-3" title=""Internet Protocol, Version 6 (IPv6) Specification"">3</a>] the IP stack is required to drop the packet. Thus,
receiving Home Address destination option and Type 2 Routing Header
at the application layer requires implementation of respective
extension headers at the IP layer in the kernel, as defined in
<a href="./rfc3775">RFC3775</a> [<a href="#ref-2" title=""Mobility Support in IPv6"">2</a>].
For receiving the Home Address destination option header, the Mobile
IPv6 implementation SHOULD follow the initial processing rules of the
Home Address destination option (<a href="#section-9.3.1">Section 9.3.1</a> of Mobile IPv6 [<a href="#ref-2" title=""Mobility Support in IPv6"">2</a>])
before passing the information to the API level. This includes
initial processing of IPSec authentication data in a packet when it
exists. Each Destination options header is returned as one ancillary
data object described by a cmsghdr structure with cmsg_level set to
IPPROTO_IPV6 and cmsg_type set to IPV6_DSTOPTS.
For sending the Home Address destination option, ancillary data can
be used to specify the option content for a single datagram. This
applies only to datagram and raw sockets, not to TCP sockets. The
Advanced API [<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>] document restricts one IPV6_xxx ancillary data
object for a particular extension header in the control buffer.
Thus, there would be a single ancillary data object for the Home
address destination option in an ancillary data buffer. If multiple
destination options are present, then the header order should be in
compliance with <a href="#section-6.3">Section 6.3</a> and 9.3.2 of the Mobile IPv6 [<a href="#ref-2" title=""Mobility Support in IPv6"">2</a>] base
specification.
For TCP data packets with the Home Address destination option, the
"sticky" option may be used for all transmitted packets. The
application can remove the sticky Home Destination option header by
calling setsockopt() for IPV6_MIPDSTOPTS with a zero option length.
Note that <a href="#section-2">Section 2</a> of this document does not encourage setting the
Home Address destination option at the user level. A Mobile IPv6
implementation should set and process the Home Address destination
<span class="grey">Chakrabarti & Nordmark Informational [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
option and Routing Header Type 2 at the kernel level. The setting of
Routing Header Type 2 and the Home Address destination option are
described in this document for completeness and flexibility to use
them in the future, if there is a need.
The following socket option parameters and cmsghdr fields may be used
for sending (although not a recommended usage):
opt level/ optname/ optval/
cmsg_level cmsg_type cmsg_data[]
------------ ------------ ------------------------
IPPROTO_IPV6 IPV6_MIPDSTOPTS ip6_dest structure
IPPROTO_IPV6 IPV6_RTHDR ip6_rthdr structure
Some IPv6 implementations may support "sticky" options [<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>] for the
IPv6 destination option for datagram and RAW sockets.
Behavior of Legacy IPv6 Socket Applications:
Legacy IPv6 applications/implementations using the Advanced Socket
API [<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>] mechanisms, upon receiving Home Address destination options
or Routing headers(Type 2), will discard the packet as per Sections
4.2 and 4.4 of IPV6 Protocol [<a href="#ref-3" title=""Internet Protocol, Version 6 (IPv6) Specification"">3</a>] specification, respectively;
otherwise, they should properly handle the Home Address destination
option and the Routing Header Type 2 specified in this document.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Routing Header Access Functions</span>
IPV6 Protocol [<a href="#ref-3" title=""Internet Protocol, Version 6 (IPv6) Specification"">3</a>] defines a Routing header extension header for Type
0. Thus, in order to access the IPv6 Routing header Type 2 extension
header, one MUST use type = 2 and segment = 1. The following
existing functions defined in Advanced API for IPv6 Sockets [<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>] are
supported for Mobile IPv6 applications for sending and receiving
Routing Header Type 2 headers:
For Sending:
size_t inet6_rth_space(int type, int segments);
void *inet6_rth_init(void *bp, int bp_len, int type, int segments);
int inet6_rth_add(void *bp, const struct in6_addr *addr);
For Receiving:
int inet6_rth_segments(const void *bp);
struct in6_addr *inet6_rth_getaddr(const void *bp, int index);
NOTE: Reversing operation is not possible using the Route Header Type
2 extension header. Thus, inet6_rth_reverse() is not used.
<span class="grey">Chakrabarti & Nordmark Informational [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
Detailed descriptions and examples of accessing an IPv6 Routing
Header are discussed in the Advanced Sockets API for IPv6 [<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>].
However, <a href="#section-7">Section 7</a> of Advanced API for IPv6 Sockets [<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>] indicates
that multiple types of routing headers can be received as multiple
ancillary data objects to the application (with cmsg_type set to
IPV6_RTHDR). Currently, there are no API functions defined to return
the routing header type. However, this document does not define a
helper function, since it is easy to access the Routing Header Type
field just as easily as the ip6r_segleft field. An excerpt of a code
sample is provided for extracting the type of the received routing
header:
if (msg.msg_controllen != 0 &&
cmsgptr->cmsg_level == IPPROTO_IPV6 &&
cmsgptr->cmsg_type == IPV6_RTHDR) {
struct in6_addr *in6;
char asciiname[INET6_ADDRSTRLEN];
struct ip6_rthdr *rthdr;
int segments, route_type;
rthdr = (struct ip6_rthdr *)extptr;
segments = inet6_rth_segments(extptr);
printf("route (%d segments, %d left): ",
segments, rthdr->ip6r_segleft);
route_type = rthdr->ip6r_type;
if (route_type == 2) {
printf ("Routing header Type 2 present\n");
}
}
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Content of Type 2 Routing Header</span>
It is recommended that no portable applications send Type 2 Routing
Header ancillary data from the application layer, since many
implementations take care of that at the kernel layer and may not
support the API for sending Type 2 Routing Header.
Mobile IPv6 [<a href="#ref-2" title=""Mobility Support in IPv6"">2</a>] defines the Type 2 Routing Header to allow the packet
to be routed directly from a correspondent to the mobile node's
care-of address. The mobile node's care-of address is inserted into
the IPv6 Destination Address field. Once the packet arrives at the
care-of address, the mobile node retrieves its home address from the
routing header, and this is used as the final destination address for
the received IPv6 packet.
<span class="grey">Chakrabarti & Nordmark Informational [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
For user-level applications that receive Type 2 Routing Header,
inet6_rth_getaddr() returns the care-of address or on-the-wire
destination address of the received packet. This complies with the
existing Routing header Type=0 processing for IPv6 [<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>].
Thus, on the receive side, the socket application will always receive
data packets at its original home address. The implementations are
responsible for processing the Type 2 Routing Header packet as per
Mobile IPv6 RFC [<a href="#ref-2" title=""Mobility Support in IPv6"">2</a>] before passing the Type 2 Routing Header
information to the Socket API.
If a pure IPv6 [<a href="#ref-3" title=""Internet Protocol, Version 6 (IPv6) Specification"">3</a>] system receives the Routing Header Type 2 packets,
it will follow the process described in <a href="#section-4.4">Section 4.4</a> of the IPv6 [<a href="#ref-3" title=""Internet Protocol, Version 6 (IPv6) Specification"">3</a>]
base specification.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Order of Extension Headers for Home Address Destination Options</span>
<a href="#section-6.3">Section 6.3</a> of Mobile IPV6 [<a href="#ref-2" title=""Mobility Support in IPv6"">2</a>] defines the extension header order for
the Home address destination option.
Routing Header
Home Address Destination Option
Fragment Header
AH/ESP Header
IPv6 [<a href="#ref-3" title=""Internet Protocol, Version 6 (IPv6) Specification"">3</a>] specifies that the destination header can be either before
the Routing header or after the AH/ESP header if they are all
present.
Thus, when the Home Address destination option is present along with
other extension headers, the order will be:
Hop-by-Hop Options header
Destination Options header
Routing header
Destination Options [Home Address Option]
Fragment header
Authentication header
Encapsulating Security Payload header
Destination Options header
upper-layer header
Any user-level implementation or application that sends the Home
address destination option through ancillary data objects should
follow the order extension header defined in this document when using
IPV6_MIPDSTOPTS socket options.
<span class="grey">Chakrabarti & Nordmark Informational [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Home Address Destination Option Access Functions</span>
The application must enable the IPV6_RECVDSTOPTS socket option in
order to receive the Home Address destination option (error checking
is not performed in the example for brevity):
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on));
Each Destination option header is returned as one ancillary data
object described by a cmsghdr structure, with cmsg_level set to
IPPROTO_IPV6 and cmsg_type set to IPV6_DSTOPTS.
The received side Home Address destination option is further
processed by calling the inet6_opt_next(), inet6_opt_find(), and
inet6_opt_get_value() functions as defined in Advanced API for IPv6
sockets [<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>].
This document assumes that portable Mobile IPv6 applications will not
send a Home Address Destination Option from the application level, as
the Mobile IPv6 implementation underneath takes care of sending the
Home Address option and the routing header type 2 at the kernel.
However, some embedded software implementations may implement the
IPv6 packet processing/sending at the user-level; those
implementations may choose to provide the API support for sending a
home-address option at the application layer. In this case, the Home
Address destination options are normally constructed by using the
inet6_opt_init(), inet6_opt_append(), inet6_opt_finish(), and
inet6_opt_set_val() functions, described in <a href="#section-10">Section 10</a> of the
Advanced sockets API for IPv6 [<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>].
<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>. Content of Home Address Destination Option</span>
The received ancillary data object for the Home Address destination
option SHOULD contain the care-of address of the mobile node. It is
assumed that the initial processing of the Home Address destination
option will verify the validity of the home address, as described in
Sections <a href="#section-6.3">6.3</a> and <a href="#section-9.5">9.5</a> of the Mobile IPv6 Specification [<a href="#ref-2" title=""Mobility Support in IPv6"">2</a>], and swap
the source address of the packet (COA) with the contents of Home
Address destination option.
Note that whether or not these new APIs are used, the sender's home
address is contained in the source address (which is passed to the
application using the socket-level functions recvfrom(), recvmsg(),
accept(), and getpeername()). This is necessary for:
<span class="grey">Chakrabarti & Nordmark Informational [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
maintaining consistency between simple user-level applications
running between mobile nodes and the diagnostic applications on
the home agent or correspondent node that use this API;
obtaining the COA address of the mobile node when the Home Address
destination option is used; and
maintaining consistency of existing IPv6 Socket APIs and
processing of the Home Address destination option.
If an implementation supports send-side Home Address destination API,
then it must follow the same rule for data content as specified in
Mobile IPv6 RFC [<a href="#ref-2" title=""Mobility Support in IPv6"">2</a>] for sending a home-address option. Thus, the
home-address option will contain the home address, and the
implementation will use the care-of address as the source address of
the outgoing packet. If the implementation uses IPSec, then it
should use the content of Home Address destination option as the
source address of the packet for security association. Note that
regular user applications must not set the home address destination
option.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Mobility Protocol Headers</span>
Mobile IPv6 [<a href="#ref-2" title=""Mobility Support in IPv6"">2</a>] defines a new IPv6 protocol header to carry mobility
messages between Mobile Nodes, Home Agents and Correspondent Nodes.
These protocol headers carry Mobile IPv6 Binding messages as well as
Return Routability [<a href="#ref-2" title=""Mobility Support in IPv6"">2</a>] messages. Currently the specification [<a href="#ref-2" title=""Mobility Support in IPv6"">2</a>]
does not allow transport packets (piggybacking) along with the
mobility messages. Thus the mobility protocol header can be accessed
through an IPv6 RAW socket. An IPv6 RAW socket that is opened for
protocol IPPROTO_MH should always be able to see all the MH (Mobility
Header) packets. It is possible that future applications may
implement part of Mobile IPv6 signal processing at the application
level. Having a RAW socket interface may also enable an application
to execute the Return Routability protocol or other future
authentication protocol involving the mobility header at the user-
level.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Receiving and Sending Mobility Header Messages</span>
This specification recommends that the IPv6 RAW sockets mechanism
send and receive Mobility Header (MH) packets. The behavior is
similar to ICMPV6 processing, where the kernel passes a copy of the
mobility header packet to the receiving socket. Depending on the
implementation, the kernel may process the mobility header in
addition to passing the mobility header to the application. In order
to comply with the restriction in the Advanced Sockets API for IPv6
[<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>], applications should set the IPV6_CHECKSUM socket option with
<span class="grey">Chakrabarti & Nordmark Informational [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
IPPROTO_MH protocol RAW Sockets. A Mobile IPv6 implementation that
supports the Mobile IPv6 API must implement Mobility Header API
checksum calculations by default at the kernel for both incoming and
outbound paths. A Mobile IPv6 implementation must not return error
on the IPV6_CHECKSUM socket option setting, even if the socket option
is a NO-OP function for that implementation because it verifies the
checksum at the kernel level. The Mobility Header checksum procedure
is described in the Mobile IPv6 Protocol [<a href="#ref-2" title=""Mobility Support in IPv6"">2</a>] specification. Again,
for application portability it is recommended that the applications
set the IPV6_CHECKSUM socket option along with the RAW sockets for
IPPROTO_MH protocol.
As an example, a program that wants to send or receive a mobility
header protocol(MH) could open a socket as follows (for brevity, the
error checking is not performed in the example below):
fd = socket(AF_INET6, SOCK_RAW, IPPROTO_MH);
int offset = 4;
setsockopt(fd, IPPROTO_IPV6, IPV6_CHECKSUM, &offset,
sizeof(offset));
For example, if an implementation likes to handle HOTI/HOT and COTI/
COT message processing, it can do so by using IPv6 RAW Sockets for
IPPROTO_MH at the application layer. The same application may also
set the IPV6_RECVDSTOPTS socket option for receiving Home Address
destination option in a binding update [<a href="#ref-2" title=""Mobility Support in IPv6"">2</a>] from the mobile node.
IPv6 RAW sockets are described in <a href="#section-3">Section 3</a> of the IPv6 Advanced
Socket API [<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>] specification. All data sent and received via raw
sockets must be in network byte order. The data structures that are
defined in this document are in network byte order, and they are
believed to be supported by most compilers to hold packet formats
directly for transmission on the wire.
The usual send/recv functions for datagram should be used for the
Mobile IPv6 RAW sockets in order to send and receive data,
respectively.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Protocols File</span>
Many hosts provide the file /etc/protocols, which contains the names
of the various IP protocols and their protocol numbers. The protocol
numbers are obtained through function getprotoXXX() functions.
The following addition should be made to the /etc/protocols file, in
addition to what is defined in <a href="#section-2.4">Section 2.4</a> of the Advanced Sockets
API for IPv6 [<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>].
<span class="grey">Chakrabarti & Nordmark Informational [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
The protocol number for Mobility Header:
(<a href="http://www.iana.org/assignments/protocol-numbers">http://www.iana.org/assignments/protocol-numbers</a>)
ipv6-mh 135 # Mobility Protocol Header
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IPv4-Mapped IPv6 Addresses</span>
The various socket options and ancillary data specifications defined
in this document apply only to true IPv6 sockets. It is possible to
create an IPv6 socket that actually sends and receives IPv4 packets,
using IPv4-mapped IPv6 addresses, but the mapping of the options
defined in this document to an IPv4 datagram is beyond the scope of
this document. The above statement is in compliance with <a href="#section-13">Section 13</a>
of the IPv6 Socket API [<a href="#ref-1" title=""Advanced Sockets Application Program Interface (API) for IPv6"">1</a>].
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
The setting of the Home Address Destination option and Route Header
Type 2 IPV6_RTHDR socket option may not be allowed at the application
level in order to prevent denial-of-service attacks or man-in-the-
middle attacks by hackers. Sending and receiving of mobility header
messages are possible by IPv6 RAW sockets. Thus, it is assumed that
this operation is only possible by privileged users. However, this
API does not prevent the existing security threat from a hacker
sending a bogus mobility header or other IPv6 packets using the Home
Address option and Type 2 Routing Header extensions.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. IANA Considerations</span>
This document does not define a new protocol. However, it uses the
Mobility Header Protocol for IPv6 to define an API for the
/etc/protocols file. (ref: <a href="http://www.iana.org/assignments/protocol-numbers">http://www.iana.org/assignments/protocol-</a>
<a href="http://www.iana.org/assignments/protocol-numbers">numbers</a>)
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Acknowledgements</span>
Thanks to Brian Haley for the thorough review of this document and
many helpful comments. Keiichi Shima, Alexandru Petrescu, Ryuji
Wakikawa, Vijay Devarapalli, Jim Bound, Suvidh Mathur, Karen Nielsen,
Mark Borst, Vladislav Yasevich, and other mobile-ip working group
members provided valuable input. Antti Tuominen suggested the
routing header type function for this API document. During IESG
review, Bill Fenner suggested accessing the routing header type
directly for being consistent with <a href="./rfc3542">RFC3542</a>. A new socket option for
Home Address Destination Option is added per Bill Fenner's suggestion
for clarity of extension header orders. Thanks to Thomas Narten and
Jari Arkko for the review of this document.
<span class="grey">Chakrabarti & Nordmark Informational [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. References</span>
<span class="h3"><a class="selflink" id="section-12.1" href="#section-12.1">12.1</a>. Normative References</span>
[<a id="ref-1">1</a>] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced
Sockets Application Program Interface (API) for IPv6", <a href="./rfc3542">RFC 3542</a>,
May 2003.
[<a id="ref-2">2</a>] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", <a href="./rfc3775">RFC 3775</a>, June 2004.
<span class="h3"><a class="selflink" id="section-12.2" href="#section-12.2">12.2</a>. Informative References</span>
[<a id="ref-3">3</a>] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", <a href="./rfc2460">RFC 2460</a>, December 1998.
[<a id="ref-4">4</a>] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", <a href="./rfc3963">RFC 3963</a>,
January 2005.
[<a id="ref-5">5</a>] Nordmark, E., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22IPv6+Socket+API+for+source+address+selection%22'>"IPv6 Socket API for source address selection"</a>,
Work in Progress, July 2005.
[<a id="ref-6">6</a>] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", <a href="./rfc3493">RFC 3493</a>,
February 2003.
Authors' Addresses
Samita Chakrabarti
EMail: samitac2@gmail.com
Erik Nordmark
Sun Microsystems
17 Network Circle
Menlo Park, CA 94025
USA
Phone: +1 650 786 2921
EMail: erik.nordmark@sun.com
<span class="grey">Chakrabarti & Nordmark Informational [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc4584">RFC 4584</a> Sockets for API for Mobile IPv6 July 2006</span>
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Chakrabarti & Nordmark Informational [Page 25]
</pre>
|
