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
|
<pre>Network Working Group C. DeSanti
Request for Comments: 3831 Cisco Systems
Category: Standards Track July 2004
<span class="h1">Transmission of IPv6 Packets over Fibre Channel</span>
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document specifies the way of encapsulating IPv6 packets over
Fibre Channel, and the method of forming IPv6 link-local addresses
and statelessly autoconfigured addresses on Fibre Channel networks.
Table Of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Summary of Fibre Channel . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Overview . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.2">2.2</a>. Identifiers and Login. . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.3">2.3</a>. FC Levels and Frame Format . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.4">2.4</a>. Sequences and Exchanges . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3">3</a>. IPv6 Capable Nx_Ports. . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4">4</a>. IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. FC Sequence Format . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.2">4.2</a>. FC Classes of Service. . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.3">4.3</a>. FC Header Code Points. . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.4">4.4</a>. FC Network_Header. . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4.5">4.5</a>. LLC/SNAP Header. . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4.6">4.6</a>. Bit and Byte Ordering. . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5">5</a>. Maximum Transfer Unit. . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-6">6</a>. Stateless Address Autoconfiguration. . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-6.1">6.1</a>. IPv6 Interface Identifier and Address Prefix . . . . . . <a href="#page-10">10</a>
6.2. Generating an Interface ID from a Format 1
N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
6.3. Generating an Interface ID from a Format 2
N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<span class="grey">DeSanti Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3831">RFC 3831</a> IPv6 over Fibre Channel July 2004</span>
6.4. Generating an Interface ID from a Format 5
N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
6.5. Generating an Interface ID from an EUI-64
mapped N_Port_Name . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-7">7</a>. Link-Local Addresses . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-8">8</a>. Address Mapping for Unicast. . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-9">9</a>. Address Mapping for Multicast. . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-10">10</a>. Sequence Management. . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-11">11</a>. Exchange Management. . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-12">12</a>. Security Considerations. . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-13">13</a>. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-14">14</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-14.1">14.1</a>. Normative References. . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-14.2">14.2</a>. Informative References. . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#appendix-A">A</a>. Transmission of a Broadcast FC Sequence over FC Topologies . . <a href="#page-20">20</a>
<a href="#appendix-B">B</a>. Validation of the <N_Port_Name, N_Port_ID> mapping . . . . . . <a href="#page-21">21</a>
<a href="#appendix-C">C</a>. Fibre Channel Bit and Byte Numbering Guidance. . . . . . . . . <a href="#page-22">22</a>
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-23">23</a>
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . <a href="#page-24">24</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Fibre Channel (FC) is a high speed serial interface technology that
supports several Upper Layer Protocols including Small Computer
System Interface (SCSI) and IPv4 as specified in [<a href="#ref-IPFC" title=""IP and ARP over Fibre Channel"">IPFC</a>].
The purpose of this document is to specify a way of encapsulating IP
version 6 [<a href="#ref-IPv6" title=""Internet Protocol, Version 6 (IPv6) Specification"">IPv6</a>] over Fibre Channel and to describe a method of
forming IPv6 link-local addresses [<a href="#ref-AARCH" title=""Internet Protocol Version 6 (IPv6) Addressing Architecture"">AARCH</a>] and statelessly
autoconfigured addresses on Fibre Channel networks. This document
also describes the content of the Source/Target Link-layer Address
option used in Neighbor Discovery [<a href="#ref-DISC" title=""Neighbor Discovery for IP Version 6 (IPv6)"">DISC</a>] when the messages are
transmitted on a Fibre Channel network.
Warning to readers familiar with Fibre Channel: both Fibre Channel
and IETF standards use the same byte transmission order. However,
the bit numbering is different. See <a href="#appendix-C">Appendix C</a> for guidance.
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="#ref-KEYWORDS" title=""Key words for use in RFCs to Indicate Requirement Levels"">KEYWORDS</a>].
<span class="grey">DeSanti Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3831">RFC 3831</a> IPv6 over Fibre Channel July 2004</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Summary of Fibre Channel</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Overview</span>
Fibre Channel (FC) is a gigabit speed network technology primarily
used for Storage Networking. Fibre Channel is standardized in the
T11 Technical Committee of the InterNational Committee for
Information Technology Standards (INCITS), an American National
Standard Institute (ANSI) accredited standards committee.
Fibre Channel devices are called Nodes. Each Node has one or more
Ports that connect to Ports of other devices. Fibre Channel may be
implemented using any combination of the following three topologies:
- a point-to-point link between two Ports;
- a set of Ports interconnected by a switching network called a
Fabric, as defined in [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>];
- a set of Ports interconnected with a loop topology, as defined in
[<a href="#ref-FC-AL-2" title=""Fibre Channel - Arbitrated Loop-2 (FC-AL-2)"">FC-AL-2</a>].
A Node Port is more precisely called an N_Port. A Node Port that is
capable of operating in a loop topology using the loop specific
protocols is designated as an NL_Port. The term Nx_Port is used to
generically indicate these two kinds of Node Port.
A Fabric Port is more precisely called an F_Port. A Fabric Port that
is capable of operating in a loop topology using the loop specific
protocols is designated as an FL_Port. The term Fx_Port is used to
generically indicate these two kinds of Fabric Port.
From an IPv6 point of view, a Fibre Channel network, built with any
combination of the FC topologies described above, is an IPv6 Link
[<a href="#ref-IPv6" title=""Internet Protocol, Version 6 (IPv6) Specification"">IPv6</a>]. IPv6-capable Nx_Ports are what [<a href="#ref-IPv6" title=""Internet Protocol, Version 6 (IPv6) Specification"">IPv6</a>] calls Interfaces.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Identifiers and Login</span>
Fibre Channel entities are identified by permanent 64 bit long
Name_Identifiers. [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>] defines several formats of
Name_Identifiers. The value of the first four bits defines the
format of a Name_Identifier. These names are referred to in a more
precise manner as follows:
- an Nx_Port's Name_Identifier is called N_Port_Name;
- an Fx_Port's Name_Identifier is called F_Port_Name;
- a Node's Name_Identifier is called Node_Name;
- a Fabric's Name_Identifier is called Fabric_Name.
<span class="grey">DeSanti Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3831">RFC 3831</a> IPv6 over Fibre Channel July 2004</span>
An Nx_Port connected to a Fibre Channel network is associated with
two identifiers, its permanent N_Port_Name and a volatile 24 bit
address called N_Port_ID. The N_Port_Name is used to identify the
Nx_Port, while the N_Port_ID is used for communications among
Nx_Ports.
Each Nx_Port acquires an N_Port_ID from the Fabric by performing a
process called Fabric Login or FLOGI. The FLOGI process is used also
to negotiate several communications parameters between the Nx_Port
and the Fabric, such as the receive data field size, which determines
the maximum size of the Fibre Channel frames that may be transferred
between the Nx_Port and the Fabric.
Before effective communication may take place between two Nx_Ports,
they must complete a process called Port Login or PLOGI. The PLOGI
process provides each Nx_Port with the other Nx_Port's N_Port_Name,
and negotiates several communication parameters, such as the receive
data field size, which determines the maximum size of the Fibre
Channel frames that may be transferred between the two Nx_Ports.
Both Fabric Login and Port Login may be explicit, i.e., performed
using specific FC control messages (called Extended Link Services or
ELS), or implicit, in which the parameters are specified by
configuration or other methods.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. FC Levels and Frame Format</span>
[<a id="ref-FC-FS">FC-FS</a>] describes the Fibre Channel protocol using 5 different
levels. The FC-2 and FC-4 levels are relevant for this
specification. The FC-2 level defines the FC frame format, the
transport services, and control functions necessary for information
transfer. The FC-4 level supports Upper Level Protocols, such as
IPv4, IPv6 or SCSI. The Fibre Channel frame format is depicted in
figure 1.
+-----+-----------+-----------+--------//-------+-----+-----+
| | | Data Field | | |
| SOF | FC Header |<--------------------------->| CRC | EOF |
| | | Optional | Frame | | |
| | | Header(s) | Payload | | |
+-----+-----------+-----------+--------//-------+-----+-----+
Fig. 1: Fibre Channel Frame Format
The Start of Frame (SOF) and End of Frame (EOF) are special FC
transmission words that act as frame delimiters. The CRC is 4 octets
long and uses the same 32-bit polynomial used in FDDI.
<span class="grey">DeSanti Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3831">RFC 3831</a> IPv6 over Fibre Channel July 2004</span>
The FC Header is 24 octets long and contains several fields
associated with the identification and control of the Data Field.
The Data Field is of variable size, ranging from 0 to 2112 octets,
and includes the user data in the Frame Payload field, and Optional
Headers. The currently defined Optional Headers are:
- ESP_Header;
- Network_Header;
- Association_Header;
- Device_Header.
The value of the SOF field determines the FC Class of service
associated with the frame. Five Classes of service are specified in
[<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>]. They are distinguished primarily by the method of flow
control between the communicating Nx_Ports and by the level of data
integrity provided. A given Fabric or Nx_Port may support one or
more of the following Classes of service:
- Class 1: Dedicated physical connection with delivery confirmation;
- Class 2: Frame multiplexed service with delivery confirmation;
- Class 3: Datagram service;
- Class 4: Fractional bandwidth;
- Class 6: Reliable multicast via dedicated connections.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Sequences and Exchanges</span>
An application level payload such as IPv6 is called Information Unit
at the FC-4 level of Fibre Channel. Each FC-4 Information Unit is
mapped to an FC Sequence by the FC-2 level. An FC Sequence consists
of one or more FC frames related by the value of the Sequence_ID
(SEQ_ID) field of the FC Header.
The maximum data that may be carried by an FC frame is 2112 octets.
The maximum usable frame size depends on the Fabric and Nx_Port
implementations and is negotiated during the Login process. Whenever
an Information Unit to be transmitted exceeds this value, the FC-2
level segments it into multiple FC frames, sent as a single Sequence.
The receiving Nx_Port reassembles the Sequence of frames and delivers
a reassembled Information Unit to the FC-4 level. The Sequence Count
(SEQ_CNT) field of the FC Header may be used to ensure frame
ordering.
Multiple Sequences may be related together as belonging to the same
FC Exchange. The Exchange is a mechanism used by two Nx_Ports to
identify and manage an operation between them. The Exchange is
opened when the operation is started between the two Nx_Ports, and
closed when the operation ends. FC frames belonging to the same
<span class="grey">DeSanti Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3831">RFC 3831</a> IPv6 over Fibre Channel July 2004</span>
Exchange are related by the value of the Exchange_ID fields in the FC
Header. An Originator Exchange_ID (OX_ID) and a Responder
Exchange_ID (RX_ID) uniquely identify the Exchange.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. IPv6 Capable Nx_Ports</span>
This specification requires an IPv6 capable Nx_Port to have the
following properties:
- The format of its N_Port_Name MUST be one of 0x1, 0x2, 0x5, 0xC,
0xD, 0xE, 0xF (see <a href="#section-6.1">section 6.1</a>). IPv6 support for other
Name_Identifier formats is outside the scope of this
specification;
- It MUST support Class 3;
- It MUST support continuously increasing SEQ_CNT [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>];
- It MUST be able to transmit and receive an FC-4 Information Unit
at least 1304 octets long;
- It SHOULD support a receive data field size for Device_Data FC
frames of at least 1024 octets.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IPv6 Encapsulation</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. FC Sequence Format</span>
An IPv6 packet is mapped to an Information Unit at the FC-4 level of
Fibre Channel, which in turn is mapped to an FC Sequence by the FC-2
level. An FC Information Unit containing an IPv6 packet MUST carry
the FC Network_Header [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>] and the LLC/SNAP header [<a href="#ref-IEEE-LLC" title=""IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture"">IEEE-LLC</a>],
resulting in the FC Information Unit format depicted in figure 2.
<span class="grey">DeSanti Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3831">RFC 3831</a> IPv6 over Fibre Channel July 2004</span>
+---------------+---------------+---------------+---------------+
| |
+- -+
| Network_Header |
+- (16 octets) -+
| |
+- -+
| |
+---------------+---------------+---------------+---------------+
| LLC/SNAP header |
+- (8 octets) -+
| |
+---------------+---------------+---------------+---------------+
| |
+- -+
/ IPv6 Packet /
/ /
+- -+
| |
+---------------+---------------+---------------+---------------+
Fig. 2: FC Information Unit Mapping an IPv6 Packet
The FC ESP_Header [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>] MAY be used to secure the FC frames
composing the FC Sequence. [<a href="#ref-AH" title=""IP Authentication Header"">AH</a>] or [<a href="#ref-ESP" title=""IP Encapsulating Security Payload (ESP)"">ESP</a>] may be used to provide
security at the IPv6 layer. Other types of FC Optional Header MUST
NOT be used in an IPv6 FC Sequence.
Typically, a Sequence consists of more than one frame. Only the
first frame of the Sequence MUST include the FC Network_Header and
the LLC/SNAP header. The other frames MUST NOT include them, as
depicted in figure 3.
First Frame of an IPv6 FC Sequence
+-----------+-------------------+-----------------+-------//--------+
| FC Header | FC Network_Header | LLC/SNAP header | First chunk of |
| | | | the IPv6 Packet |
+-----------+-------------------+-----------------+-------//--------+
Subsequent Frames of an IPv6 FC Sequence
+-----------+-----------------//------------------+
| FC Header | Additional chunk of the IPv6 Packet |
+-----------+----------------//-------------------+
Fig. 3: Optional Headers in an IPv6 FC Sequence
<span class="grey">DeSanti Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3831">RFC 3831</a> IPv6 over Fibre Channel July 2004</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. FC Classes of Service</span>
This specification uses FC Class 3. IPv6 packets carrying Neighbor
Discovery [<a href="#ref-DISC" title=""Neighbor Discovery for IP Version 6 (IPv6)"">DISC</a>] messages MUST be encapsulated in Class 3 FC frames.
Other IPv6 packets SHOULD use Class 3 as well. The use of other
Classes of service is outside the scope of this specification.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. FC Header Code Points</span>
The fields of the Fibre Channel Header are depicted in figure 4. The
D_ID and S_ID fields contain respectively the destination N_Port_ID
and the source N_Port_ID. To encapsulate IPv6 over Fibre Channel the
following code points MUST be used:
- R_CTL: 0x04 (Device_Data frame with Unsolicited Data Information
Category [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>])
- TYPE: 0x05 (IP over Fibre Channel)
- CS_CTL/Prio: 0x0
- DF_CTL: 0x20 (Network_Header) for the first FC frame of an IPv6
Sequence, 0x00 for the following FC frames. If the FC ESP_Header
is used, then 0x60 for the first FC frame of an IPv6 Sequence,
0x40 for the following FC frames.
- F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID, Parameter: see <a href="#section-10">section 10</a>,
<a href="#section-11">section 11</a>, and [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>] for additional requirements.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R_CTL | D_ID |
+---------------+---------------+---------------+---------------+
| CS_CTL/Prio | S_ID |
+---------------+---------------+---------------+---------------+
| TYPE | F_CTL |
+---------------+---------------+---------------+---------------+
| SEQ_ID | DF_CTL | SEQ_CNT |
+---------------+---------------+---------------+---------------+
| OX_ID | RX_ID |
+---------------+---------------+---------------+---------------+
| Parameter |
+---------------+---------------+---------------+---------------+
Fig. 4: FC Header Format
<span class="grey">DeSanti Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3831">RFC 3831</a> IPv6 over Fibre Channel July 2004</span>
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. FC Network_Header</span>
The fields of the FC Network_Header are depicted in figure 5. For
use with IPv6 the N_Port_Names formats MUST be one of 0x1, 0x2, 0x5,
0xC, 0xD, 0xE, 0xF. IPv6 support for other Name_Identifier formats
is outside the scope of this specification.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Destination N_Port_Name -+
| |
+---------------------------------------------------------------+
| |
+- Source N_Port_Name -+
| |
+---------------------------------------------------------------+
Fig. 5: FC Network_Header Format
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. LLC/SNAP Header</span>
The fields of the LLC/SNAP Header [<a href="#ref-IEEE-LLC" title=""IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture"">IEEE-LLC</a>] are depicted in figure
6. To encapsulate IPv6 over Fibre Channel the following code points
MUST be used:
- DSAP: 0xAA
- SSAP: 0xAA
- CTRL: 0x03
- OUI: 0x00-00-00
- PID: 0x86-DD
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSAP | SSAP | CTRL | OUI |
+---------------+---------------+---------------+---------------+
| OUI | PID |
+---------------+---------------+---------------+---------------+
Fig. 6: LLC/SNAP Header Format
<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>. Bit and Byte Ordering</span>
IPv6 packets are mapped to the FC-4 level using the big-endian byte
ordering that corresponds to the standard network byte order or
canonical form.
<span class="grey">DeSanti Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3831">RFC 3831</a> IPv6 over Fibre Channel July 2004</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Maximum Transfer Unit</span>
The default MTU size for IPv6 [<a href="#ref-IPv6" title=""Internet Protocol, Version 6 (IPv6) Specification"">IPv6</a>] packets over Fibre Channel is
65280 octets. This size may be reduced by a Router Advertisement
[<a href="#ref-DISC" title=""Neighbor Discovery for IP Version 6 (IPv6)"">DISC</a>] containing an MTU option that specifies a smaller MTU, or by
manual configuration of each Nx_Port. However, as required by
[<a href="#ref-IPv6" title=""Internet Protocol, Version 6 (IPv6) Specification"">IPv6</a>], the MTU MUST NOT be lower than 1280 octets. If a Router
Advertisement received on an Nx_Port has an MTU option specifying an
MTU larger than 65280, or larger than a manually configured value,
that MTU option MAY be logged to system management but MUST be
otherwise ignored.
As the default MTU size far exceeds the message sizes typically used
in the Internet, an IPv6 over FC implementation SHOULD implement Path
MTU Discovery [<a href="#ref-PMTUD" title=""Path MTU Discovery for IP version 6"">PMTUD</a>], or at least maintain different MTU values for
on-link and off-link destinations.
For correct operation in a routed environment, it is critically
important to configure an appropriate MTU option in Router
Advertisements.
For correct operation when mixed media (e.g., Ethernet and Fibre
Channel) are bridged together, the smallest MTU of all the media must
be advertised by routers in an MTU option. If there are no routers
present, this MTU must be manually configured in each node which is
connected to a medium with a default MTU larger than the smallest
MTU.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Stateless Address Autoconfiguration</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. IPv6 Interface Identifier and Address Prefix</span>
The IPv6 Interface ID [<a href="#ref-AARCH" title=""Internet Protocol Version 6 (IPv6) Addressing Architecture"">AARCH</a>] for an Nx_Port is based on the EUI-64
address [<a href="#ref-EUI64" title=""Guidelines For 64-bit Global Identifier (EUI-64)"">EUI64</a>] derived from the Nx_Port's N_Port_Name. The IPv6
Interface Identifier is obtained by complementing the Universal/Local
bit of the OUI field of the derived EUI-64 address.
[<a id="ref-FC-FS">FC-FS</a>] specifies a method to map format 0x1 (IEEE 48 bit address),
or 0x2 (IEEE Extended), or 0x5 (IEEE Registered) FC Name_Identifiers
in EUI-64 addresses. This allows the usage of these Name_Identifiers
to support IPv6. [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>] also defines EUI-64 mapped FC
Name_Identifiers (formats 0xC, 0xD, 0xE, and 0xF), that are derived
from an EUI-64 address. It is possible to reverse this address
mapping to obtain the original EUI-64 address in order to support
IPv6.
<span class="grey">DeSanti Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3831">RFC 3831</a> IPv6 over Fibre Channel July 2004</span>
Stateless address autoconfiguration MUST be performed as specified in
[<a href="#ref-ACONF" title=""IPv6 Stateless Address Autoconfiguration"">ACONF</a>]. An IPv6 Address Prefix used for stateless address
autoconfiguration of an Nx_Port MUST have a length of 64 bits.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Generating an Interface ID from a Format 1 N_Port_Name</span>
The Name_Identifier format 0x1 is depicted in figure 7.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1| 0x000 | OUI |
+-------+-------+---------------+---------------+---------------+
| OUI | VSID |
+---------------+---------------+---------------+---------------+
Fig. 7: Format 0x1 Name_Identifier
The EUI-64 address derived from this Name_Identifier has the format
depicted in figure 8 [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 0 0 1| VSID |
+---------------+---------------+-------+-------+-------+-------+
| VSID | 0x000 |
+---------------+---------------+-------+-------+---------------+
Fig. 8: EUI-64 Address from a Format 0x1 Name_Identifier
The IPv6 Interface Identifier is obtained from this EUI-64 address by
complementing the U/L bit in the OUI field. So the OUI in the IPv6
Interface ID is exactly as in the FC Name_Identifier. The resulting
IPv6 Interface Identifier has local scope [<a href="#ref-AARCH" title=""Internet Protocol Version 6 (IPv6) Addressing Architecture"">AARCH</a>] and the format
depicted in figure 9.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 0 0 1| VSID |
+---------------+---------------+-------+-------+-------+-------+
| VSID | 0x000 |
+---------------+---------------+-------+-------+---------------+
Fig. 9: IPv6 Interface ID from a Format 0x1 Name_Identifier
<span class="grey">DeSanti Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3831">RFC 3831</a> IPv6 over Fibre Channel July 2004</span>
As an example, the FC Name_Identifier 0x10-00-34-63-46-AB-CD-EF
generates the IPv6 Interface Identifier 3463:461A:BCDE:F000.
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Generating an Interface ID from a Format 2 N_Port_Name</span>
The Name_Identifier format 0x2 is depicted in figure 10.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0| Vendor Specific | OUI |
+-------+-------+---------------+---------------+---------------+
| OUI | VSID |
+---------------+---------------+---------------+---------------+
Fig. 10: Format 0x2 Name_Identifier
The EUI-64 address derived from this Name_Identifier has the format
depicted in figure 11 [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 0 1 0| VSID |
+---------------+-----------------------+-------+-------+-------+
| VSID | Vendor Specific |
+---------------+-----------------------+-------+---------------+
Fig. 11: EUI-64 Address from a Format 0x2 Name_Identifier
The IPv6 Interface Identifier is obtained from this EUI-64 address by
complementing the U/L bit in the OUI field. So the OUI in the IPv6
Interface ID is exactly as in the FC Name_Identifier. The resulting
IPv6 Interface Identifier has local scope [<a href="#ref-AARCH" title=""Internet Protocol Version 6 (IPv6) Addressing Architecture"">AARCH</a>] and the format
depicted in figure 12.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 0 1 0| VSID |
+---------------+-----------------------+-------+-------+-------+
| VSID | Vendor Specific |
+---------------+-----------------------+-------+---------------+
Fig. 12: IPv6 Interface ID from a Format 0x2 Name_Identifier
As an example, the FC Name_Identifier 0x27-89-34-63-46-AB-CD-EF
generates the IPv6 Interface Identifier 3463:462A:BCDE:F789.
<span class="grey">DeSanti Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3831">RFC 3831</a> IPv6 over Fibre Channel July 2004</span>
<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>. Generating an Interface ID from a Format 5 N_Port_Name</span>
The Name_Identifier format 0x5 is depicted in figure 13.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1| OUI | VSID |
+-------+-------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 13: Format 0x5 Name_Identifier
The EUI-64 address derived from this Name_Identifier has the format
depicted in figure 14 [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 1 0 1| VSID |
+---------------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 14: EUI-64 Address from a Format 0x5 Name_Identifier
The IPv6 Interface Identifier is obtained from this EUI-64 address
complementing the U/L bit in the OUI field. So the OUI in the IPv6
Interface ID is exactly as in the FC Name_Identifier. The resulting
IPv6 Interface Identifier has local scope [<a href="#ref-AARCH" title=""Internet Protocol Version 6 (IPv6) Addressing Architecture"">AARCH</a>] and the format
depicted in figure 15.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 1 0 1| VSID |
+---------------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 15: IPv6 Interface ID from a Format 0x5 Name_Identifier
As an example, the FC Name_Identifier 0x53-46-34-6A-BC-DE-F7-89
generates the IPv6 Interface Identifier 3463:465A:BCDE:F789.
<span class="grey">DeSanti Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc3831">RFC 3831</a> IPv6 over Fibre Channel July 2004</span>
<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>. Generating an Interface ID from an EUI-64 mapped N_Port_Name</span>
The EUI-64 mapped Name_Identifiers formats (formats 0xC through 0xF)
are derived from an EUI-64 address by compressing the OUI field of
such addresses. The compression is performed by removing from the
OUI the Universal/Local and Individual/Group bits, and by putting
bits 0 to 5 of the OUI in the first octet of the Name_Identifier, and
bits 8 to 23 of the OUI in the second and third octet of the
Name_Identifier, as shown in figure 16.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1| OUI[0..5] | OUI[8..23] | VSID |
+---+-----------+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 16: EUI-64 Mapped Name_Identifiers Format
The EUI-64 address used to generate the Name_Identifier shown in
figure 16 has the format depicted in figure 17.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI[0..5] |0 0| OUI[8..23] | VSID |
+-----------+---+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 17: EUI-64 Address from an EUI-64 Mapped Name_Identifier
The IPv6 Interface Identifier is obtained from this EUI-64 address by
complementing the U/L bit in the OUI field. The resulting IPv6
Interface Identifier has global scope [<a href="#ref-AARCH" title=""Internet Protocol Version 6 (IPv6) Addressing Architecture"">AARCH</a>] and the format depicted
in figure 18.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI[0..5] |1 0| OUI[8..23] | VSID |
+-----------+---+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 18: IPv6 Interface ID from an EUI-64 Mapped Name_Identifier
<span class="grey">DeSanti Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc3831">RFC 3831</a> IPv6 over Fibre Channel July 2004</span>
As an example, the FC Name_Identifier 0xCD-63-46-AB-01-25-78-9A
generates the IPv6 Interface Identifier 3663:46AB:0125:789A.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Link-Local Addresses</span>
The IPv6 link-local address [<a href="#ref-AARCH" title=""Internet Protocol Version 6 (IPv6) Addressing Architecture"">AARCH</a>] for an Nx_Port is formed by
appending the Interface Identifier, as defined in <a href="#section-6">section 6</a>, to the
prefix FE80::/64. The resulting address is depicted in figure 19.
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
Fig. 19: IPv6 link-local Address Format
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Address Mapping for Unicast</span>
An Nx_Port has two kinds of Fibre Channel addresses:
- a non-volatile 64-bit address, called N_Port_Name;
- a volatile 24-bit address, called N_Port_ID.
The N_Port_Name is used to uniquely identify the Nx_Port, while the
N_Port_ID is used to route frames to the Nx_Port. Both FC addresses
are required to resolve an IPv6 unicast address. The fact that the
N_Port_ID is volatile implies that an Nx_Port MUST validate the
mapping between its N_Port_Name and N_Port_ID when certain Fibre
Channel events occur (see <a href="#appendix-B">Appendix B</a>).
The procedure for mapping IPv6 unicast addresses into Fibre Channel
link-layer addresses uses the Neighbor Discovery Protocol [<a href="#ref-DISC" title=""Neighbor Discovery for IP Version 6 (IPv6)"">DISC</a>].
The Source/Target Link-layer Address option has the format depicted
in figure 20 when the link layer is Fibre Channel.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 2 | Reserved |
+---------------+---------------+---------------+---------------+
| |
+- N_Port_Name -+
| |
+---------------+---------------+---------------+---------------+
| Reserved | N_Port_ID |
+---------------+---------------+---------------+---------------+
Fig. 20: Source/Target Link-layer Address option for Fibre Channel
<span class="grey">DeSanti Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc3831">RFC 3831</a> IPv6 over Fibre Channel July 2004</span>
Type: 1 for Source Link-layer address.
2 for Target Link-layer address.
Length: 2 (in units of 8 octets).
N_Port_Name: This field contains the Nx_Port's N_Port_Name.
N_Port_ID: This field contains the Nx_Port's N_Port_ID.
Reserved fields MUST be zero when transmitting, and MUST be ignored
when receiving.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Address Mapping for Multicast</span>
By default, all best-effort IPv6 multicast packets MUST be mapped to
FC Sequences addressed to the broadcast N_Port_ID 0xFF-FF-FF. In
particular, datagrams addressed to all-nodes multicast address,
all-routers multicast address, and solicited-node multicast addresses
[<a href="#ref-AARCH" title=""Internet Protocol Version 6 (IPv6) Addressing Architecture"">AARCH</a>] MUST be sent as Class 3 FC Sequences addressed to the
broadcast N_Port_ID 0xFF-FF-FF. In this case, the Destination
N_Port_Name field of the FC Network_Header MUST be set to the value
0x10-00-FF-FF-FF-FF-FF-FF. <a href="#appendix-A">Appendix A</a> specifies how to transmit a
Class 3 broadcast FC Sequence over various Fibre Channel topologies.
An Nx_Port supporting IPv6 MUST be able to map a received broadcast
Class 3 Device_Data FC frame to an implicit Port Login context in
order to handle IPv6 multicast packets. The receive data field size
of this implicit Port Login MUST be the same across all the Nx_Ports
connected to the same Fabric, otherwise FC broadcast transmission
does not work. In order to reduce the need for FC Sequence
segmentation, the receive data field size of this implicit Port Login
SHOULD be 1024 octets. This receive data field size requirement
applies to broadcast Device_Data FC frames, not to ELSs.
Receiving an FC Sequence carrying an IPv6 multicast packet MAY
trigger some additional processing by the Nx_Port if that IPv6 packet
requires a unicast reply. In this case, if a valid Port Login to the
Nx_Port that sent the IPv6 multicast packet does not exist, the
Nx_Port MUST perform such a Port Login, and then use it for the
unicast IPv6 reply. In the case of Neighbor Discovery messages
[<a href="#ref-DISC" title=""Neighbor Discovery for IP Version 6 (IPv6)"">DISC</a>], the N_Port_ID to which the Port Login is directed is taken
from the N_Port_ID field of the Source/Target Link-layer Address
option.
As an example, an Nx_Port processes a received broadcast FC Sequence
carrying an IPv6 multicast unsolicited router advertisement [<a href="#ref-DISC" title=""Neighbor Discovery for IP Version 6 (IPv6)"">DISC</a>]
simply by passing the carried IPv6 packet to the IPv6 layer.
Instead, if a received broadcast FC Sequence carries an IPv6
multicast solicitation message [<a href="#ref-DISC" title=""Neighbor Discovery for IP Version 6 (IPv6)"">DISC</a>] requiring a unicast reply, and
<span class="grey">DeSanti Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc3831">RFC 3831</a> IPv6 over Fibre Channel July 2004</span>
no valid Port Login exists with the Nx_Port sender of the multicast
packet, then a Port Login MUST be performed in order to send the
unicast reply message. If a received broadcast FC Sequence carries
an IPv6 multicast solicitation message [<a href="#ref-DISC" title=""Neighbor Discovery for IP Version 6 (IPv6)"">DISC</a>] requiring a multicast
reply, the reply is sent to the broadcast N_Port_ID 0xFF-FF-FF.
Best-effort IPv6 multicast for other multicast group addresses MAY
use Fibre Channel Multicast Groups [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>], if supported by the
particular FC topology and implementation.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Sequence Management</span>
FC Sequences are REQUIRED to be non-streamed. In order to avoid
missing FC frame aliasing by Sequence_ID reuse, an Nx_Port supporting
IPv6 is REQUIRED to use continuously increasing SEQ_CNT [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>].
Each Exchange MUST start with SEQ_CNT = 0 in the first frame, and
every frame transmitted after that MUST increment the previous
SEQ_CNT by one. Any frames received from the other N_Port in the
Exchange shall have no effect on the transmitted SEQ_CNT.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Exchange Management</span>
To transfer IPv6 packets, each Nx_Port MUST have a dedicated Exchange
for sending data to each Nx_Port in the network and a dedicated
Exchange for receiving data from each Nx_Port.
An Exchange Responder is not required to assign RX_IDs. If an RX_ID
of 0xFFFF is assigned, the Exchange Responder is identifying
Exchanges based on S_ID / D_ID / OX_ID only.
When an Exchange is created between two Nx_Ports for unicast IPv6
packets, it remains active while the Nx_Ports are logged in with each
other. Each FC broadcast and ELS [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>] SHOULD use a separate short
lived Exchange.
For IPv6, Exchanges MUST NOT transfer Sequence Initiative, because
they are used in a unidirectional mode. The Sequence Initiative bit
in the F_CTL field of the FC Header [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>] MUST be set to 0.
The mechanism for aging or expiring exchanges based on activity,
timeout, or other methods is outside the scope of this document.
The Exchange Originator MAY terminate Exchanges by setting the F_CTL
LS bit [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>]. Exchanges MAY be torn down by the Exchange
Originator or Exchange Responder by using the ABTS (Abort Sequence)
protocol [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>]. IPv6 Exchanges SHOULD NOT be terminated by Logout,
since this may terminate active Exchanges on other FC-4s [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>].
<span class="grey">DeSanti Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc3831">RFC 3831</a> IPv6 over Fibre Channel July 2004</span>
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Security Considerations</span>
IPv6 does not introduce any additional security concerns beyond those
that already exist within the Fibre Channel protocols. Zoning
techniques based on FC Name Server masking (soft zoning) do not work
with IPv6, because IPv6 over Fibre Channel does not use the FC Name
Server. The FC ESP_Header [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>] may be used to secure the FC
frames composing FC Sequences carrying IPv6 packets. All the
techniques defined to secure IPv6 traffic at the IPv6 layer may be
used in a Fibre Channel environment.
<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>. Acknowledgments</span>
The author would like to acknowledge the authors of [<a href="#ref-IPFC" title=""IP and ARP over Fibre Channel"">IPFC</a>], [<a href="#ref-ETHER" title=""Transmission of IPv6 Packets over Ethernet Networks"">ETHER</a>],
and [<a href="#ref-IPv6-1394" title=""Transmission of IPv6 Packets over IEEE 1394 Networks"">IPv6-1394</a>], since some part of this document has been derived
from them, as well as the ANSI INCITS T11.3 Task Group members who
reviewed this document.
<span class="h2"><a class="selflink" id="section-14" href="#section-14">14</a>. References</span>
<span class="h3"><a class="selflink" id="section-14.1" href="#section-14.1">14.1</a>. Normative References</span>
[<a id="ref-FC-FS">FC-FS</a>] ANSI INCITS 373-2003, "Fibre Channel - Framing and
Signaling (FC-FS)".
[<a id="ref-FC-AL-2">FC-AL-2</a>] ANSI INCITS 332-1999, "Fibre Channel - Arbitrated Loop-2
(FC-AL-2)".
[<a id="ref-IPv6">IPv6</a>] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", <a href="./rfc2460">RFC 2460</a>, December 1998.
[<a id="ref-AARCH">AARCH</a>] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", <a href="./rfc3513">RFC 3513</a>, April 2003.
[<a id="ref-ACONF">ACONF</a>] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", <a href="./rfc2462">RFC 2462</a>, December 1998.
[<a id="ref-DISC">DISC</a>] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", <a href="./rfc2461">RFC 2461</a>, December
1998.
[<a id="ref-PMTUD">PMTUD</a>] McCann, J., Deering, S., and J. Mogul, "Path MTU
Discovery for IP version 6", <a href="./rfc1981">RFC 1981</a>, August 1996.
[<a id="ref-IEEE-LLC">IEEE-LLC</a>] IEEE Std 802-2001, "IEEE Standard for Local and
Metropolitan Area Networks: Overview and Architecture".
<span class="grey">DeSanti Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc3831">RFC 3831</a> IPv6 over Fibre Channel July 2004</span>
[<a id="ref-KEYWORDS">KEYWORDS</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.
<span class="h3"><a class="selflink" id="section-14.2" href="#section-14.2">14.2</a>. Informative References</span>
[<a id="ref-IPFC">IPFC</a>] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP
over Fibre Channel", <a href="./rfc2625">RFC 2625</a>, June 1999.
[<a id="ref-AH">AH</a>] Kent, S. and R. Atkinson, "IP Authentication Header", <a href="./rfc2402">RFC</a>
<a href="./rfc2402">2402</a>, November 1998.
[<a id="ref-ESP">ESP</a>] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", <a href="./rfc2406">RFC 2406</a>, November 1998.
[<a id="ref-EUI64">EUI64</a>] "Guidelines For 64-bit Global Identifier (EUI-64)",
<a href="http://standards.ieee.org/db/oui/tutorials/EUI64.html">http://standards.ieee.org/db/oui/tutorials/EUI64.html</a>
[<a id="ref-ETHER">ETHER</a>] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", <a href="./rfc2464">RFC 2464</a>, December 1998.
[<a id="ref-IPv6-1394">IPv6-1394</a>] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets
over IEEE 1394 Networks", <a href="./rfc3146">RFC 3146</a>, October 2001.
<span class="grey">DeSanti Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc3831">RFC 3831</a> IPv6 over Fibre Channel July 2004</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">A</a>. Transmission of a Broadcast FC Sequence over FC Topologies</span>
<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>. Point-to-Point Topology</span>
No particular mechanisms are required for this case. The Nx_Port
connected at the other side of the cable receives the broadcast FC
Sequence having D_ID 0xFFFFFF.
<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a>. Private Loop Topology</span>
An NL_Port attached to a private loop MUST transmit a Class 3
broadcast FC Sequence by using the OPN(fr) primitive signal
[<a href="#ref-FC-AL-2" title=""Fibre Channel - Arbitrated Loop-2 (FC-AL-2)"">FC-AL-2</a>].
a) The source NL_Port first sends an Open Broadcast Replicate
(OPN(fr)) primitive signal, forcing all the NL_Ports in the loop
(except itself) to replicate the frames that they receive while
examining the FC Header's D_ID field.
b) The source NL_Port then removes the OPN(fr) signal when it returns
to it.
c) The source NL_Port then sends the Class 3 broadcast FC Sequence
having D_ID 0xFFFFFF.
<span class="h3"><a class="selflink" id="appendix-A.3" href="#appendix-A.3">A.3</a>. Public Loop Topology</span>
An NL_Port attached to a public loop MUST NOT use the OPN(fr)
primitive signal. Rather, it MUST send the Class 3 broadcast FC
Sequence having D_ID 0xFFFFFF to the FL_Port at AL_PA = 0x00
[<a href="#ref-FC-AL-2" title=""Fibre Channel - Arbitrated Loop-2 (FC-AL-2)"">FC-AL-2</a>].
The Fabric propagates the broadcast to all other FC_Ports [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>],
including the FL_Port which the broadcast arrives on. This includes
all F_Ports, and other FL_Ports.
Each FL_Port propagates the broadcast by using the primitive signal
OPN(fr), in order to prepare the loop to receive the broadcast
sequence.
<span class="h3"><a class="selflink" id="appendix-A.4" href="#appendix-A.4">A.4</a>. Fabric Topology</span>
An N_Port connected to an F_Port MUST transmit the Class 3 broadcast
FC Sequence having D_ID 0xFFFFFF to the F_Port. The Fabric
propagates the broadcast to all other FC_Ports [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>].
<span class="grey">DeSanti Standards Track [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc3831">RFC 3831</a> IPv6 over Fibre Channel July 2004</span>
<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">B</a>. Validation of the <N_Port_Name, N_Port_ID> mapping</span>
<span class="h3"><a class="selflink" id="appendix-B.1" href="#appendix-B.1">B.1</a>. Overview</span>
At all times, the <N_Port_Name, N_Port_ID> mapping must be valid
before use.
After an FC link interruption occurs, the N_Port_ID of an Nx_Port may
change, as well as the N_Port_IDs of all other Nx_Ports that have
previously performed Port Login with this Nx_Port. Because of this,
address validation is required after a LIP in a loop topology
[<a href="#ref-FC-AL-2" title=""Fibre Channel - Arbitrated Loop-2 (FC-AL-2)"">FC-AL-2</a>] or after NOS/OLS in a point-to-point topology [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>].
N_Port_IDs do not change as a result of Link Reset (LR) [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>], thus
address validation is not required in this case.
<span class="h3"><a class="selflink" id="appendix-B.2" href="#appendix-B.2">B.2</a>. FC Layer Address Validation in a Point-to-Point Topology</span>
No validation is required after LR. In a point-to-point topology,
NOS/OLS causes implicit Logout of each N_Port and after a NOS/OLS
each N_Port must again perform a Port Login [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>].
<span class="h3"><a class="selflink" id="appendix-B.3" href="#appendix-B.3">B.3</a>. FC Layer Address Validation in a Private Loop Topology</span>
After a LIP [<a href="#ref-FC-AL-2" title=""Fibre Channel - Arbitrated Loop-2 (FC-AL-2)"">FC-AL-2</a>], an NL_Port must not transmit any data to
another NL_Port until the address of the other port has been
validated. The validation consists of completing either ADISC or
PDISC [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>].
For a requester, this specification prohibits PDISC and requires
ADISC. As a responder, an implementation may need to respond to both
ADISC and PDISC for compatibility with other FC specifications.
If the three FC addresses (N_Port_ID, N_Port_Name, Node_Name) of a
logged remote NL_Port exactly match the values prior to the LIP, then
any active Exchange with that NL_Port may continue.
If any of the three FC addresses has changed, then the remote NL_Port
must be logged out.
If an NL_Port's N_Port_ID changes after a LIP, then all active logged
in NL_Ports must be logged out.
<span class="grey">DeSanti Standards Track [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc3831">RFC 3831</a> IPv6 over Fibre Channel July 2004</span>
<span class="h3"><a class="selflink" id="appendix-B.4" href="#appendix-B.4">B.4</a>. FC Layer Address Validation in a Public Loop Topology</span>
A FAN ELS may be sent by the Fabric to all known previously logged in
NL_Ports following an initialization event. Therefore, after a LIP
[<a href="#ref-FC-AL-2" title=""Fibre Channel - Arbitrated Loop-2 (FC-AL-2)"">FC-AL-2</a>], NL_Ports may wait for this notification to arrive, or they
may perform an FLOGI.
If the F_Port_Name and Fabric_Name contained in the FAN ELS or FLOGI
response exactly match the values before the LIP and if the AL_PA
[<a href="#ref-FC-AL-2" title=""Fibre Channel - Arbitrated Loop-2 (FC-AL-2)"">FC-AL-2</a>] obtained by the NL_Port is the same as the one before the
LIP, then the port may resume all Exchanges. If not, then FLOGI must
be performed with the Fabric and all logged in Nx_Ports must be
logged out.
A public loop NL_Port must perform the private loop validation as
specified in section B.3 to any NL_Port on the local loop that has an
N_Port_ID of the form 0x00-00-XX.
<span class="h3"><a class="selflink" id="appendix-B.5" href="#appendix-B.5">B.5</a>. FC Layer Address Validation in a Fabric Topology</span>
No validation is required after LR (link reset).
After NOS/OLS, an N_Port must perform FLOGI. If, after FLOGI, the
N_Port's N_Port_ID, the F_Port_Name, and the Fabric_Name are the same
as before the NOS/OLS, then the N_Port may resume all Exchanges. If
not, all logged in Nx_Ports must be logged out [<a href="#ref-FC-FS" title=""Fibre Channel - Framing and Signaling (FC-FS)"">FC-FS</a>].
<span class="h2"><a class="selflink" id="appendix-C" href="#appendix-C">C</a>. Fibre Channel Bit and Byte Numbering Guidance</span>
Both Fibre Channel and IETF standards use the same byte transmission
order. However, the bit numbering is different.
Fibre Channel bit numbering can be observed if the data structure
heading shown in figure 21 is cut and pasted at the top of the
figures present in this document.
3 2 1 0
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 21: Fibre Channel Bit Numbering
<span class="grey">DeSanti Standards Track [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc3831">RFC 3831</a> IPv6 over Fibre Channel July 2004</span>
Author's Address
Claudio DeSanti
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
USA
Phone: +1 408 853-9172
EMail: cds@cisco.com
<span class="grey">DeSanti Standards Track [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc3831">RFC 3831</a> IPv6 over Fibre Channel July 2004</span>
Full Copyright Statement
Copyright (C) The Internet Society (2004). 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 currently provided by the
Internet Society.
DeSanti Standards Track [Page 24]
</pre>
|
