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
|
<pre>Network Working Group A. Conta
Request for Comments: 2590 Lucent
Category: Standards Track A. Malis
Ascend
M. Mueller
Lucent
May 1999
<span class="h1">Transmission of IPv6 Packets over Frame Relay Networks</span>
<span class="h1">Specification</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 (1999). All Rights Reserved.
Abstract
This memo describes mechanisms for the transmission of IPv6 packets
over Frame Relay networks.
Table of Contents
<a href="#section-1">1</a>. Introduction.................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Maximum Transmission Unit....................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Frame Format.................................................<a href="#page-4">4</a>
<a href="#section-4">4</a>. Stateless Autoconfiguration..................................<a href="#page-5">5</a>
<a href="#section-4.1">4.1</a> Generating the MID field.................................<a href="#page-7">7</a>
<a href="#section-5">5</a>. Link-Local Address...........................................<a href="#page-9">9</a>
<a href="#section-6">6</a>. Address Mapping -- Unicast, Multicast........................<a href="#page-9">9</a>
<a href="#section-7">7</a>. Sending Neighbor Discovery Messages.........................<a href="#page-14">14</a>
<a href="#section-8">8</a>. Receiving Neighbor Discovery Messages.......................<a href="#page-15">15</a>
<a href="#section-9">9</a>. Security Considerations.....................................<a href="#page-15">15</a>
<a href="#section-10">10</a>. Acknowledgments............................................<a href="#page-16">16</a>
<a href="#section-11">11</a>. References.................................................<a href="#page-16">16</a>
<a href="#section-12">12</a>. Authors' Addresses.........................................<a href="#page-18">18</a>
<a href="#section-13">13</a>. Full Copyright Statement...................................<a href="#page-19">19</a>
<span class="grey">Conta, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc2590">RFC 2590</a> IPv6 over Frame Relay Networks May 1999</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document specifies the frame format for transmission of IPv6
packets over Frame Relay networks, the method of forming IPv6 link-
local addresses on Frame Relay links, and the mapping of the IPv6
addresses to Frame Relay addresses. It also specifies the content of
the Source/Target link-layer address option used in Neighbor
Discovery [ND] and Inverse Neighbor Discovery [<a href="#ref-IND" title=""Extensions to IPv6 Neighbor Discovery for Inverse Discovery"">IND</a>] messages when
those messages are transmitted over a Frame Relay link. It is part
of a set of specifications that define such IPv6 mechanisms for Non
Broadcast Multi Access (NBMA) media [<a href="#ref-IPv6-NBMA" title=""IPv6 over Non-Broadcast Multiple Access (NBMA) networks"">IPv6-NBMA</a>], [<a href="#ref-IPv6-ATM" title=""IPv6 over ATM Networks"">IPv6-ATM</a>], and a
larger set that defines such mechanisms for specific link layers
[<a href="#ref-IPv6-ETH" title=""Transmission of IPv6 packets over Ethernet Networks"">IPv6-ETH</a>], [<a href="#ref-IPv6-FDDI" title=""Transmission of IPv6 packets over FDDI Networks"">IPv6-FDDI</a>], [<a href="#ref-IPv6-PPP" title=""IP Version 6 over PPP"">IPv6-PPP</a>], [<a href="#ref-IPv6-ATM" title=""IPv6 over ATM Networks"">IPv6-ATM</a>], etc...
The information in this document applies to Frame Relay devices which
serve as end stations (DTEs) on a public or private Frame Relay
network (for example, provided by a common carrier or PTT.) Frame
Relay end stations can be IPv6 hosts or routers. In this document
they are referred to as nodes.
In a Frame Relay network, a number of virtual circuits form the
connections between the attached stations (nodes). The resulting set
of interconnected devices forms a private Frame Relay group which may
be either fully interconnected with a complete "mesh" of virtual
circuits, or only partially interconnected. In either case, each
virtual circuit is uniquely identified at each Frame Relay interface
(card) by a Data Link Connection Identifier (DLCI). In most
circumstances, DLCIs have strictly local significance at each Frame
Relay interface.
A Frame Relay virtual circuit acts like a virtual-link (also referred
to as logical-link), with its own link parameters, distinct from the
parameters of other virtual circuits established on the same wire or
fiber. Such parameters are the input/output maximum frame size,
incoming/outgoing requested/agreed throughput, incoming/outgoing
acceptable throughput, incoming/outgoing burst size,
incoming/outgoing frame rate.
By default a DLCI is 10 bits in length. Frame Relay specifications
define also 16, 17, or 23 bit DLCIs. The former is not used, while
the latter two are suggested for use with SVCs.
Frame Relay virtual circuits can be created administratively as
Permanent Virtual Circuits -- PVCs -- or dynamically as Switched
Virtual Circuits -- SVCs. The mechanisms defined in this document
are intended to apply to both permanent and switched Frame Relay
virtual circuits, whether they are point to point or point to multi-
point.
<span class="grey">Conta, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc2590">RFC 2590</a> IPv6 over Frame Relay Networks May 1999</span>
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined
in [<a href="./rfc2119">RFC 2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Maximum Transmission Unit</span>
The IPv6 minimum MTU is defined in [<a href="#ref-IPv6" title=""Internet Protocol Version 6 Specification"">IPv6</a>].
In general, Frame Relay devices are configured to have a maximum
frame size of at least 1600 octets. Therefore, the default IPv6 MTU
size for a Frame Relay interface is considered to be 1592.
A smaller than default frame size can be configured but of course not
smaller than the minimum IPv6 MTU.
An adequate larger than default IPv6 MTU and Frame Relay frame size
can be configured to avoid fragmentation. The maximum frame size is
controlled by the CRC generation mechanisms employed at the HDLC
level. CRC16 will protect frames up to 4096 bytes in length, which
reduces the effective maximum frame size to approximately 4088 bytes.
A larger desired frame size (such as that used by FDDI or Token
Ring), would require the CRC32 mechanism, which is not yet widely
used and is not mandatory for frame relay systems conforming to Frame
Relay Forum and ITU-T standards.
In general, if upper layers provide adequate error
protection/detection mechanisms, implementations may allow
configuring a Frame Relay link with a larger than 4080 octets frame
size but with a lesser error protection/detection mechanism at link
layer. However, because IPv6 relies on the upper and lower layer
error detection, configuring the IPv6 MTU to a value larger than 4080
is strongly discouraged.
Although a Frame Relay circuit allows the definition of distinct
maximum frame sizes for input and output, for simplification
purposes, this specification assumes symmetry, i.e. the same MTU for
both input and output.
Furthermore, implementations may limit the setting of the Frame Relay
maximum frame size to the interface (link, or card) level, which then
is enforced on all of the PVCs or SVCs on that interface (on that
link, or card). For an SVC, the maximum frame size parameter
negotiated during circuit setup will not exceed the configured
maximum frame size.
<span class="grey">Conta, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc2590">RFC 2590</a> IPv6 over Frame Relay Networks May 1999</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. IPv6 Frame Format</span>
The IPv6 frame encapsulation for Frame Relay (for both PVCs and SVCs)
follows [<a href="#ref-ENCAPS" title=""Multiprotocol Interconnect over Frame Relay"">ENCAPS</a>], which allows a VC to carry IPv6 packets along with
other protocol packets. The NLPID frame format is used, in which the
IPv6 NLPID has a value of 0x8E:
0 1 (Octets)
+-----------------------+-----------------------+
(Octets)0 | |
/ Q.922 Address /
/ (length 'n' equals 2 or 4) /
| |
+-----------------------+-----------------------+
n | Control (UI) 0x03 | NLPID 0x8E | NLPID
+-----------------------+-----------------------+ indicating
n+2 | . | IPv6
/ . /
/ IPv6 packet /
| . |
+-----------------------+-----------------------+
| |
+ FCS +
| |
+-----------------------+-----------------------+
"n" is the length of the Q.922 address which can be 2 or 4 octets.
The Q.922 representation of a DLCI (in canonical order - the first
bit is stored in the least significant, i.e., the right-most bit
of a byte in memory) [<a href="#ref-CANON" title=""A Caution on the Canonical Ordering of Link-Layer Addresses"">CANON</a>] is the following:
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(octet) 0 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | DLCI(low order) | 0 | 0 | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
10 bits DLCI
<span class="grey">Conta, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc2590">RFC 2590</a> IPv6 over Frame Relay Networks May 1999</span>
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(octet) 0 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | DLCI | 0 | 0 | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | DLCI(low order) | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | unused (set to 0) | 1 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
17 bits DLCI
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(octet) 0 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----
1 | DLCI | 0 | 0 | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | DLCI | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | DLCI (low order) | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
23 bits DLCI
The encapsulation of data or control messages exchanged by various
protocols that use SNAP encapsulation (with their own PIDs) is not
affected. The encoding of the IPv6 protocol identifier in such
messages MUST be done according to the specifications of those
protocols, and [<a href="#ref-ASSNUM" title=""Assigned Numbers"">ASSNUM</a>].
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Stateless Autoconfiguration</span>
An interface identifier [<a href="#ref-AARCH" title=""IPv6 Addressing Architecture"">AARCH</a>] for an IPv6 Frame Relay interface
must be unique on a Frame Relay link [<a href="#ref-AARCH" title=""IPv6 Addressing Architecture"">AARCH</a>], and must be unique on
each of the virtual links represented by the VCs terminated on the
interface.
The interface identifier for the Frame Relay interface is locally
generated by the IPv6 module.
Each virtual circuit in a Frame Relay network is uniquely identified
on a Frame Relay interface by a DLCI. Furthermore, a DLCI can be seen
as an identification of the end point of a virtual circuit on a Frame
Relay interface. Since each Frame Relay VC is configured or
established separately, and acts like an independent virtual-link
from other VCs in the network, or on the interface, link, wire or
<span class="grey">Conta, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc2590">RFC 2590</a> IPv6 over Frame Relay Networks May 1999</span>
fiber, it seems beneficial to view each VC's termination point on the
Frame Relay interface as a "pseudo-interface" or "logical-interface"
overlaid on the Frame Relay interface. Furthermore, it seems
beneficial to be able to generate and associate an IPv6
autoconfigured address (including an IPv6 link local address) to each
"pseudo-interface", i.e. end-point of a VC, i.e. to each DLCI on a
Frame Relay interface.
In order to achieve the benefits described above, the mechanisms
specified in this document suggest constructing the Frame Relay
interface identifier from 3 distinct fields (Fig.1):
(a) The "EUI bits" field. Bits 6 and 7 of the first octet,
representing the EUI-64 "universal/local" and respectively
"individual/group" bits converted to IPv6 use. The former is set
to zero to reflect that the 64 bit interface identifier value
has local significance [<a href="#ref-AARCH" title=""IPv6 Addressing Architecture"">AARCH</a>]. The latter is set to 0 to
reflect the unicast address [<a href="#ref-AARCH" title=""IPv6 Addressing Architecture"">AARCH</a>].
(b) The "Mid" field. A 38 bit field which is generated with the
purpose of adding uniqueness to the interface identifier.
(c) The "DLCI" field. A 24 bit field that MAY hold a 10, 17, or 23
bit DLCI value which MUST be extended with 0's to 24 bits. A
DLCI based interface identifier -- which contains a valid DLCI
-- SHOULD be generated as a result of successfully establishing
a VC -- PVC or SVC.
If a DLCI is not known, the field MUST be set to the
"unspecified DLCI" value which consists of setting each of the
24 bits to 1.
Since DLCIs are local to a Frame Relay node, it is possible to have
Frame Relay distinct virtual circuits within a Frame Relay network
identified with the same DLCI values.
<span class="grey">Conta, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc2590">RFC 2590</a> IPv6 over Frame Relay Networks May 1999</span>
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(Octets) 0 | |"EUI bits" |
+ +-----+-----+
1 | |
+ +
2 | "Mid" |
+ +
3 | |
+ +
4 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | |
+ +
6 | "DLCI" |
+ +
7 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
Fig.1 Frame Relay Pseudo-Interface Identifier
The Duplicate Address Detection specified in [<a href="#ref-AUTOCONF" title=""IPv6 Stateless Autoconfiguration"">AUTOCONF</a>] is used
repeatedly during the interface identifier and local-link address
generation process, until the generated identifier and consequently
the link-local address on the link -- VC -- are unique.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a> Generating the "Mid" field.</span>
The "Mid" can be generated in multiple ways. This specification
suggests two mechanisms:
(b.1) "Use of Local Administrative Numbers"
The "Mid" is filled with the result of merging:
(b.1.1) A random number of 6 bits in length (Fig.2).
(b.1.2) The Frame Relay Node Identifier -- 16 bits -- is a user
administered value used to locally identify a Frame Relay
node (Fig.2).
(b.1.3) The Frame Relay Link Identifier -- 16 bits -- is a numerical
representation of the Frame Relay interface or link (Fig.2).
<span class="grey">Conta, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc2590">RFC 2590</a> IPv6 over Frame Relay Networks May 1999</span>
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(Octets) 0 | Random Number | MBZ |
+-----------------------------------+-----+-----+
1 | |
+ Frame Relay Node Identifier +
2 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | |
+ Frame Relay Link Identifier +
4 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | |
+ +
6 | "DLCI" |
+ +
7 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
Fig.2 Frame Relay Pseudo-Interface Identifier
or,
(b.2) "Use of The Frame Relay address - E.164 [<a href="#ref-E164" title=""Telephone Network and ISDN Operation, Numbering, Routing, amd Mobile Service"">E164</a>], X.121
[<a href="#ref-X25" title=""Information Technology -- Data Communications -- X.25 Packet Layer Protocol for Data Terminal Equipment"">X25</a>] numbers, or NSAP [<a href="#ref-NSAP" title=""Information Processing Systems -- Data Communications -- Network Service Definition Addendum 2: Network Layer Addressing"">NSAP</a>] address"
If a Frame Relay interface has an E.164 or a X.121 number, or an
NSAP address, the "Mid" field MUST be filled in with a number
resulted from it as follows: the number represented by the BCD
encoding of the E.164 or X.121 number, or the binary encoding of
the NSAP address is truncated to 38 bits (Fig.3). Since the Frame
Relay interface identifier has a "local" significance, the use of
such a value has no real practical purposes other than adding to
the uniqueness of the interface identifier on the link. Therefore
the truncation can be performed on the high order or low order
bits. If the high order bits truncation does not provide
uniqueness on the link -- perhaps the DLCI value is not unique --
this most likely means that the VC spans more for instance than a
national and/or international destination area for an E.164
number, and therefore the truncation of the low order bits should
be performed next, which most likely will provide the desired
uniqueness.
<span class="grey">Conta, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc2590">RFC 2590</a> IPv6 over Frame Relay Networks May 1999</span>
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(Octets) 0 | | MBZ |
+ +-----+-----+
1 | |
+ E.164, X.121 (BCD encoding) +
2 | or NSAP Address |
+ +
3 | (truncated to 38 bits) |
+ +
4 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | |
+ +
6 | "DLCI" |
+ +
7 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
Fig.3 Frame Relay (Pseudo) Interface Identifier
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Link-Local Addresses</span>
The IPv6 link-local address [<a href="#ref-AARCH" title=""IPv6 Addressing Architecture"">AARCH</a>] for an IPv6 Frame Relay interface
is formed by appending the interface identifier, formed as defined
above, to the prefix FE80::/64 [<a href="#ref-AARCH" title=""IPv6 Addressing Architecture"">AARCH</a>].
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) |Frame Relay Interface Ident.|
+----------+-----------------------+----------------------------+
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Address Mapping -- Unicast, Multicast</span>
The procedure for mapping IPv6 addresses to link-layer addresses is
described in [<a href="#ref-IPv6-ND" title=""Neighbor Discovery for IP Version 6 (IPv6)"">IPv6-ND</a>]. Additionally, extensions to Neighbor
Discovery (ND) that allow the mapping of link-layer addresses to IPv6
addresses are defined as Inverse Neighbor Discovery (IND) in [<a href="#ref-IND" title=""Extensions to IPv6 Neighbor Discovery for Inverse Discovery"">IND</a>].
This document defines the formats of the link-layer address fields
used by ND and IND. This specification does not define an algorithmic
mapping of IPv6 multicast addresses to Frame Relay link-layer
addresses.
The Source/Target Link-layer Address option used in Neighbor
Discovery and Inverse Neighbor Discovery messages for a Frame Relay
link follows the general rules defined by [<a href="#ref-IPv6-ND" title=""Neighbor Discovery for IP Version 6 (IPv6)"">IPv6-ND</a>]. IPv6 addresses
can map two type of identifiers equivalent to link-layer addresses:
<span class="grey">Conta, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc2590">RFC 2590</a> IPv6 over Frame Relay Networks May 1999</span>
DLCIs, and Frame Relay Addresses. Therefore, for Frame Relay, this
document defines two distinct formats for the ND and IND messages
Link-Layer Address field:
(a) DLCI Format -- used in ND and/or IND messages on VCs that were
established prior to the ND or IND message exchange -- mostly
PVCs. The use on SVCs makes sense with Inverse Neighbor
Discovery [<a href="#ref-IND" title=""Extensions to IPv6 Neighbor Discovery for Inverse Discovery"">IND</a>] messages if IND is employed after the successful
establishing of an SVC to gather information about other IPv6
addresses assigned to the remote node and that SVC.
(b) Frame Relay Address Format -- used mostly prior to establishing
a new SVC, to get the Frame Relay remote node identifier
(link-layer address) mapping to a certain IPv6 address.
Note: An implementation may hold both types of link layer
identifiers in the Neighbor Discovery cache. Additionally, in
case of multiple VCs between two nodes, one node's Neighbor
Discovery cache may hold a mapping of one of the remote node's
IPv6 addresses to each and every DLCI identifying the VCs.
The mechanisms which in such an implementation would make the
distinction between the Neighbor Discovery Cache mapping of an
IPv6 address to a "Frame Relay Address Format" and a "DLCI
Format" link-layer address, or among several mappings to a "DLCI
Format" addresses are beyond the scope of this specification.
The use of the override "O" bit in the advertisement messages
that contain the above Link-Layer Address formats SHOULD be
consistent with the [ND] specifications. Additionally, there
should be consistency related to the type of Link-Layer Address
format: an implementation should override one address format in
its Neighbor Discovery cache with the same type of address
format.
The "DLCI Format" is defined as follows:
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
0 | Type |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | Length |
+-----+-----+-----+-----+-----+-----+-----+-----+
<span class="grey">Conta, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc2590">RFC 2590</a> IPv6 over Frame Relay Networks May 1999</span>
with a DLCI (Q.922 address) encoded as option value:
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | | 1 | 1 |
+ unused +-----+-----+
3 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
4 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | DLCI(low order) | 0 | 0 | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
6 | |
+ Padding +
7 | (zeros) |
+-----+-----+-----+-----+-----+-----+-----+-----+
10 bits DLCI
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | | 1 | 1 |
+ unused +-----+-----+
3 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
4 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | DLCI | 0 | 0 | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
6 | DLCI(low order) | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 | unused (set to 0) | 1 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
17 bits DLCI
<span class="grey">Conta, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc2590">RFC 2590</a> IPv6 over Frame Relay Networks May 1999</span>
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | | 1 | 1 |
+ unused +-----+-----+
3 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
4 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----
5 | DLCI | 0 | 0 | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
6 | DLCI | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 | DLCI (low order) | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
23 bits DLCI
Option fields:
Type 1 for Source Link-layer address.
2 for Target Link-layer address.
Length The Length of the Option (including the Type
and Length fields) in units of 8 octets.
It has the value 1.
Link-Layer Address The DLCI encoded as a Q.922 address.
Description
The "DLCI Format" option value field has two components:
(a) Address Type -- encoded in the first two bits of the first
two octets. Both bits are set to 1 to indicate the DLCI
format. The rest of the bits in the two first octets are
not used -- they MUST be set to zero on transmit and MUST
be ignored by the receiver.
(b) DLCI -- encoded as a Q.922 address padded with zeros to the
last octet of the 6 octets available for the entire Link-
Layer Address field of this format.
<span class="grey">Conta, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc2590">RFC 2590</a> IPv6 over Frame Relay Networks May 1999</span>
The "Frame Relay Address Format" is defined as follows:
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
0 | Type |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | Length |
+-----+-----+-----+-----+-----+-----+-----+-----+
with an E.164, X.121, number or NSAP address encoded as option
value:
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | size | 1 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | E.164 or X.121, or NSAP |
+--- Address Family Number ---+
4 | (Assigned Number) |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | |
/ E.164, or X.121 number (BCD encoded) /
/ or NSAP address /
4+size | |
+-----+-----+-----+-----+-----+-----+-----+-----+
5+size | |
/ Padding /
/ (zeros) /
8*Length-1| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Option fields:
Type 1 for Source Link-layer address.
2 for Target Link-layer address.
Length The length of the Option (including the
Type and Length fields) in units of 8 octet.
It may have the value:
2 -- for E.164, or X.121 numbers or NSAP
addresses not longer than 11 octets
[<a href="#ref-E164" title=""Telephone Network and ISDN Operation, Numbering, Routing, amd Mobile Service"">E164</a>], [<a href="#ref-X25" title=""Information Technology -- Data Communications -- X.25 Packet Layer Protocol for Data Terminal Equipment"">X25</a>], [<a href="#ref-NSAP" title=""Information Processing Systems -- Data Communications -- Network Service Definition Addendum 2: Network Layer Addressing"">NSAP</a>].
3 -- for NSAP addresses longer than 11 but
not longer than 19 octets.
<span class="grey">Conta, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc2590">RFC 2590</a> IPv6 over Frame Relay Networks May 1999</span>
4 -- for NSAP addresses longer than 19 octets
(not longer than the maximum NSAP address
length) [<a href="#ref-NSAP" title=""Information Processing Systems -- Data Communications -- Network Service Definition Addendum 2: Network Layer Addressing"">NSAP</a>].
Link-Layer Address The E.164, X.121, number encoded in
Binary Coded Decimal (BCD), or the NSAP
address.
Description
The "Frame Relay Address" option value has three components:
(a) Address Type -- encoded in the first two bits of the first
octet. The first bit is set to 0, the second bit is set to 1.
(b) Size -- encoded in the last (high order) 6 bits of the first
octet. The maximum value of the field is the maximum size of
the E.164, X.121, or NSAP addresses.
(c) Address Family Number -- the number assigned for the E.164,
X.121, or NSAP address family [<a href="#ref-ASSNUM" title=""Assigned Numbers"">ASSNUM</a>].
(d) E.164, X.121, number -- encoded in BCD (two digits per octet).
If the E.164, or X.121 has an even number of digits the
encoding will fill all encoding octets -- half the number of
digits. If the E.164, or X.121 number has an odd number of
digits, the lowest order digit fills only half of an octet --
it is placed in the first 4 bits of the last octet of the
E.164, or X.121 BCD encoding. The rest of the field up to the
last octet of the 11 octets available is padded with zeros.
NSAP address -- the NSAP address. It is padded with zeros if
the NSAP address does not fit in a number of octets that makes
the length of the option an even number of 8 octets.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Sending Neighbor Discovery Messages</span>
Frame Relay networks do not provide link-layer native multicasting
mechanisms. For the correct functioning of the Neighbor Discovery
mechanisms, link-layer multicasting must be emulated.
To emulate multicasting for Neighbor Discovery (ND) the node MUST
send frames carrying ND multicast packets to all VCs on a Frame Relay
interface. This applies to ND messages addressed to both all-node and
solicited-node multicast addresses. This method works well with PVCs.
A mesh of PVCs MAY be configured and dedicated to multicast traffic
only. An alternative to a mesh of PVCs is a set of point-to-
multipoint PVCs.
<span class="grey">Conta, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc2590">RFC 2590</a> IPv6 over Frame Relay Networks May 1999</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Receiving Neighbor Discovery Messages</span>
If a Neighbor Discovery Solicitation message received by a node
contains the Source link-layer address option with a DLCI, the
message MUST undergo Frame Relay specific preprocessing required for
the correct interpretation of the field during the ND protocol engine
processing. This processing is done before the Neighbor Discovery
message is processed by the Neighbor Discovery (ND) protocol engine.
The motivation for this processing is the local significance of the
DLCI fields in the Neighbor Discovery message: the DLCI significance
at the sender node is different than the DLCI significance at the
receiver node. In other words, the DLCI that identifies the Frame
Relay virtual circuit at the sender may be different than the DLCI
that identifies the virtual circuit at the receiver node.
Furthermore, the sender node may not be aware of the DLCI value at
the receiver. Therefore, the Frame Relay specific preprocessing
consists in modifying the Neighbor Discovery Solicitation message
received, by storing into the Source link-layer address option the
DLCI value of the virtual circuit on which the frame was received, as
known to the receiver node. The DLCI value being stored must be
encoded in the appropriate format (see previous sections). The
passing of the DLCI value from the Frame Relay module to the Neighbor
Discovery preprocessing module is an implementation choice.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
The mechanisms defined in this document for generating an IPv6 Frame
Relay interface identifier are intended to provide uniqueness at link
level -- virtual circuit. The protection against duplication is
achieved by way of IPv6 Stateless Autoconfiguration Duplicate Address
Detection mechanisms. Security protection against forgery or accident
at the level of the mechanisms described here is provided by the IPv6
security mechanisms [<a href="#ref-IPSEC" title=""Security Architecture for the Internet Protocol"">IPSEC</a>], [<a href="#ref-IPSEC-Auth" title=""IP Authentication Header"">IPSEC-Auth</a>], [<a href="#ref-IPSEC-ESP" title=""IP Encapsulating Security Protocol (ESP)"">IPSEC-ESP</a>] applied to
Neighbor Discovery [<a href="#ref-IPv6-ND" title=""Neighbor Discovery for IP Version 6 (IPv6)"">IPv6-ND</a>] or Inverse Neighbor Discovery [<a href="#ref-IND" title=""Extensions to IPv6 Neighbor Discovery for Inverse Discovery"">IND</a>]
messages.
To avoid an IPsec Authentication verification failure, the Frame
Relay specific preprocessing of a Neighbor Discovery Solicitation
message that contains a DLCI format Source link-layer address option,
MUST be done by the receiver node after it completed IP Security
processing.
<span class="grey">Conta, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc2590">RFC 2590</a> IPv6 over Frame Relay Networks May 1999</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgments</span>
Thanks to D. Harrington, and M. Merhar for reviewing this document
and providing useful suggestions. Also thanks to G. Armitage for his
reviewing and suggestions. Many thanks also to Thomas Narten for
suggestions on improving the document.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
[<a id="ref-AARCH">AARCH</a>] Hinden, R. and S. Deering, "IPv6 Addressing
Architecture", <a href="./rfc2373">RFC 2373</a>, July 1998.
[<a id="ref-ASSNUM">ASSNUM</a>] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
<a href="./rfc1700">RFC 1700</a>, October 1994. See also:
<a href="http://www.iana.org/numbers.html">http://www.iana.org/numbers.html</a>
[<a id="ref-AUTOCONF">AUTOCONF</a>] Thomson, S. and T. Narten, "IPv6 Stateless
Autoconfiguration", <a href="./rfc2462">RFC 2462</a>, December 1998.
[<a id="ref-CANON">CANON</a>] Narten, T. and C. Burton, "A Caution on the Canonical
Ordering of Link-Layer Addresses", <a href="./rfc2469">RFC 2469</a>, December
1998.
[<a id="ref-ENCAPS">ENCAPS</a>] Brown, C. and A. Malis, "Multiprotocol Interconnect over
Frame Relay", STD 55, <a href="./rfc2427">RFC 2427</a>, November 1998.
[<a id="ref-IND">IND</a>] Conta, A., "Extensions to IPv6 Neighbor Discovery for
Inverse Discovery", Work in Progress, December 1998.
[<a id="ref-IPv6">IPv6</a>] Deering, S. and R. Hinden, "Internet Protocol Version 6
Specification", <a href="./rfc2460">RFC 2460</a>, December 1998.
[<a id="ref-IPv6-ATM">IPv6-ATM</a>] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM
Networks", <a href="./rfc2492">RFC 2492</a>, January 1999.
[<a id="ref-IPv6-ETH">IPv6-ETH</a>] Crawford, M., "Transmission of IPv6 packets over
Ethernet Networks", <a href="./rfc2464">RFC 2464</a>, December 1998.
[<a id="ref-IPv6-FDDI">IPv6-FDDI</a>] Crawford, M., "Transmission of IPv6 packets over FDDI
Networks", <a href="./rfc2467">RFC 2467</a>, December 1998.
[<a id="ref-IPv6-NBMA">IPv6-NBMA</a>] Armitage, G., Schulter, P., Jork, M. and G. Harter,
"IPv6 over Non-Broadcast Multiple Access (NBMA)
networks", <a href="./rfc2491">RFC 2491</a>, January 1999.
[<a id="ref-IPv6-ND">IPv6-ND</a>] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", <a href="./rfc2461">RFC 2461</a>, December
1998.
<span class="grey">Conta, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc2590">RFC 2590</a> IPv6 over Frame Relay Networks May 1999</span>
[<a id="ref-IPv6-PPP">IPv6-PPP</a>] Haskin, D. and E. Allen, "IP Version 6 over PPP", <a href="./rfc2472">RFC</a>
<a href="./rfc2472">2472</a>, December 1998.
[<a id="ref-IPv6-TR">IPv6-TR</a>] Narten, T., Crawford, M. and M. Thomas, "Transmission
of IPv6 packets over Token Ring Networks", <a href="./rfc2470">RFC 2470</a>,
December 1998.
[<a id="ref-IPSEC">IPSEC</a>] Atkinson, R. and S. Kent, "Security Architecture for the
Internet Protocol", <a href="./rfc2401">RFC 2401</a>, November 1998.
[<a id="ref-IPSEC-Auth">IPSEC-Auth</a>] Atkinson, R. and S. Kent, "IP Authentication Header",
<a href="./rfc2402">RFC 2402</a>, December 1998.
[<a id="ref-IPSEC-ESP">IPSEC-ESP</a>] Atkinson, R. and S. Kent, "IP Encapsulating Security
Protocol (ESP)", <a href="./rfc2406">RFC 2406</a>, November 1998.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-E164">E164</a>] International Telecommunication Union - "Telephone
Network and ISDN Operation, Numbering, Routing, amd
Mobile Service", ITU-T Recommendation E.164, 1991.
[<a id="ref-NSAP">NSAP</a>] ISO/IEC, "Information Processing Systems -- Data
Communications -- Network Service Definition Addendum 2:
Network Layer Addressing". International Standard
8348/Addendum 2, ISO/IEC JTC 1, Switzerland 1988.
[<a id="ref-X25">X25</a>] "Information Technology -- Data Communications -- X.25
Packet Layer Protocol for Data Terminal Equipment",
International Standard 8208, March 1988.
<span class="grey">Conta, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc2590">RFC 2590</a> IPv6 over Frame Relay Networks May 1999</span>
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Authors' Addresses</span>
Alex Conta
Lucent Technologies Inc.
300 Baker Ave, Suite 100
Concord, MA 01742
Phone: +1-978-287-2842
EMail: aconta@lucent.com
Andrew Malis
Ascend Communications
1 Robbins Rd
Westford, MA 01886
Phone: +1-978-952-7414
EMail: malis@ascend.com
Martin Mueller
Lucent Technologies Inc.
300 Baker Ave, Suite 100
Concord, MA 01742
PHone: +1-978-287-2833
EMail: memueller@lucent.com
<span class="grey">Conta, et al. Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc2590">RFC 2590</a> IPv6 over Frame Relay Networks May 1999</span>
<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>. Full Copyright Statement</span>
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Conta, et al. Standards Track [Page 19]
</pre>
|
