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
|
<pre>Network Working Group T. Ogura
Request for Comments: 3572 M. Maruyama
Category: Informational NTT Network Innovation Labs
T. Yoshida
Werk Mikro Systems
July 2003
<span class="h1">Internet Protocol Version 6 over MAPOS</span>
<span class="h1">(Multiple Access Protocol Over SONET/SDH)</span>
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
IESG Note
This memo documents a way of carrying IPv6 packets over MAPOS
networks. This document is NOT the product of an IETF working group
nor is it a standards track document. It has not necessarily
benefited from the widespread and in-depth community review that
standards track documents receive.
Abstract
Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed
link-layer protocol that provides multiple access capability over a
Synchronous Optical NETwork/Synchronous Digital Hierarchy
(SONET/SDH).
This document specifies the frame format for encapsulating an IPv6
datagram in a MAPOS frame. It also specifies the method of forming
IPv6 interface identifiers, the method of detecting duplicate
addresses, and the format of the Source/Target Link-layer Addresses
option field used in IPv6 Neighbor Discovery messages.
<span class="grey">Ogura, et. al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3572">RFC 3572</a> IPv6 over MAPOS July 2003</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Frame Format for Encapsulating IPv6 Datagrams. . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Frame Format . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.2">2.2</a>. Maximum Transmission Unit (MTU). . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.3">2.3</a>. Destination Address Mapping. . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.3.1">2.3.1</a>. Unicast. . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.3.2">2.3.2</a>. Multicast . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. Interface Identifier . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4">4</a>. Duplicate Address Detection. . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5">5</a>. Source/Target Link-layer Address Option. . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-6">6</a>. Security Considerations. . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-6.1">6.1</a>. Issues concerning Link-layer Addresses . . . . . . . . . <a href="#page-10">10</a>
6.1.1. Protection against fraudulent reception
of traffic . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-6.1.2">6.1.2</a>. Protection against improper traffic. . . . . . . <a href="#page-11">11</a>
<a href="#section-6.2">6.2</a>. Uniqueness of Interface Identifiers. . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-7">7</a>. References. . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-8">8</a>. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-9">9</a>. Full Copyright Statement . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Multiple Access Protocol over SONET/SDH (MAPOS) [<a href="#ref-1" title=""MAPOS - Multiple Access protocol over SONET/SDH Version 1"">1</a>][2] is a high-
speed link-layer protocol that provides multiple access capability
over SONET/SDH. Its frame format is based on the HDLC-like (High
Level Data Link Control) framing [<a href="#ref-3" title=""PPP in HDLC-like Framing"">3</a>] for PPP. A component called a
"Frame Switch" [<a href="#ref-1" title=""MAPOS - Multiple Access protocol over SONET/SDH Version 1"">1</a>] allows multiple nodes (hosts and routers) to be
connected together in a star topology to form a LAN. Using long-haul
SONET/SDH links, the nodes on such a "SONET-LAN" can span a wide
geographical area.
This document specifies the frame format for encapsulating an
Internet Protocol version 6 (IPv6) [<a href="#ref-4" title=""Internet Protocol, Version 6 (IPv6) Specification"">4</a>] datagram in a MAPOS frame, the
method of forming IPv6 interface identifiers, the method of detecting
duplicate addresses, and the format of the Source/Target Link-layer
Addresses option field used in Neighbor Discovery messages such as
Router Solicitation, Router Advertisement, Neighbor Solicitation,
Neighbor Advertisement, and Redirect messages.
In the remainder of this document, the term "MAPOS" is used unless
the distinction between MAPOS version 1 [<a href="#ref-1" title=""MAPOS - Multiple Access protocol over SONET/SDH Version 1"">1</a>] and MAPOS 16 [<a href="#ref-2" title=""MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing"">2</a>] is
required.
<span class="grey">Ogura, et. al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3572">RFC 3572</a> IPv6 over MAPOS July 2003</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Frame Format for Encapsulating IPv6 Datagrams</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Frame Format</span>
MAPOS uses the same HDLC-like framing as PPP-over-SONET, described in
[<a href="#ref-3" title=""PPP in HDLC-like Framing"">3</a>]. The MAPOS frame begins and ends with a flag sequence 01111110
(0x7E), and the MAPOS frame header contains address, control, and
protocol fields. The address field contains a destination HDLC
address. In MAPOS 16, the address field is extended to 16 bits, and
the control field of MAPOS version 1 is omitted. The frame check
sequence (FCS) field is 16 bits long by default, but a 32-bit FCS may
be used optionally. Details of the MAPOS frame format are described
in [<a href="#ref-1" title=""MAPOS - Multiple Access protocol over SONET/SDH Version 1"">1</a>][2].
An IPv6 datagram is encapsulated in the MAPOS frame. In the case of
encapsulating an IPv6 datagram, the protocol field must contain the
value 0x0057 (hexadecimal). The IPv6 datagram is stored in the
information field which follows immediately after the protocol field.
That is, this field contains the IPv6 header followed immediately by
the payload. Figure 1 shows the frame format. The fields are
transmitted from left to right.
+----------+----------+----------+----------+
| | | Control/ | Protocol |
| Flag | Address | Address | 16 bits |
| 01111110 | 8 bits | 8 bits | (0x0057) |
+----------+----------+----------+----------+
+-------------+------------+----------+-----------
| | | | Inter-frame
| IPv6 header | FCS | Flag | fill or next
| and payload | 16/32 bits | 01111110 | address
+-------------+------------+----------+------------
Figure 1. Frame format.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Maximum Transmission Unit (MTU)</span>
The length of the information field of the MAPOS frame may vary, but
shall not exceed 65,280 (64K - 256) octets [<a href="#ref-1" title=""MAPOS - Multiple Access protocol over SONET/SDH Version 1"">1</a>][2]. The default
maximum transmission unit (MTU) is 65,280 octets.
However, the MTU size may be reduced by a Router Advertisement [<a href="#ref-5" title=""Neighbor Discovery for IP Version 6 (IPv6)"">5</a>]
containing an MTU option that specifies a smaller MTU, or by manual
configuration of each node. If a Router Advertisement received on a
MAPOS interface has an MTU option specifying an MTU larger than
65,280, or larger than a manually configured value, that MTU option
may be logged for the system management but must be otherwise
ignored.
<span class="grey">Ogura, et. al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3572">RFC 3572</a> IPv6 over MAPOS July 2003</span>
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Destination Address Mapping</span>
This section specifies the method of mapping an IPv6 destination
address to the address field in the MAPOS frame header.
<span class="h4"><a class="selflink" id="section-2.3.1" href="#section-2.3.1">2.3.1</a>. Unicast</span>
In unicasting, the address field of a MAPOS frame contains the HDLC
address that has been assigned via NSP (Node Switch Protocol) [<a href="#ref-6" title=""A MAPOS version 1 Extension - Node Switch Protocol"">6</a>] to
the MAPOS interface, which has the IPv6 unicast destination address.
In order to determine the destination HDLC address that corresponds
to an IPv6 unicast destination address, the sender uses Link-layer
Address Resolution described in [<a href="#ref-5" title=""Neighbor Discovery for IP Version 6 (IPv6)"">5</a>].
<span class="h4"><a class="selflink" id="section-2.3.2" href="#section-2.3.2">2.3.2</a>. Multicast</span>
Address resolution is never performed on IPv6 multicast addresses.
An IPv6 multicast destination address is mapped to the address field
in the MAPOS frame header as described below for MAPOS version 1 and
MAPOS 16.
MAPOS version 1:
The address field of the MAPOS version 1 frame header contains an 8-
bit-wide destination HDLC address [<a href="#ref-1" title=""MAPOS - Multiple Access protocol over SONET/SDH Version 1"">1</a>]. The least significant bit
(LSB) of the field must always be 1 to indicate the end of the field.
The most significant bit (MSB) is used to indicate whether the frame
is a unicast or a multicast frame.
In the case of an IPv6 multicast, the MSB of the address field is 1
to indicate that the frame is multicast. As described above, the LSB
of the address field is 1. The other six bits of the address field
must contain the lowest-order six bits of the IPv6 multicast address.
Figure 2 shows the address field of the MAPOS version 1 frame header
in the case of an IPv6 multicast, where D(1) through D(6) represent
the lowest-order six bits of the IPv6 multicast address. Exceptions
arise when these six bits are either all zeros or all ones. In these
cases, they should be altered to the bit sequence 111110. That is,
the address field should be 0xFD (hexadecimal).
<span class="grey">Ogura, et. al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3572">RFC 3572</a> IPv6 over MAPOS July 2003</span>
MSB LSB
+-+-+-+-+-+-+-+-+
| | | |
|1|D(6) - D(1)|1|
| | | |
+-+-+-+-+-+-+-+-+
^ ^
| |
| EA bit (always 1)
1 (multicast)
Figure 2. Address mapping in multicasting (MAPOS version 1).
MAPOS 16:
The address field of the MAPOS 16 frame header contains the 16-bit-
wide destination HDLC address [<a href="#ref-2" title=""MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing"">2</a>]. The LSB of the first octet must
always be 0 to indicate the continuation of this field, and the LSB
of the second octet must always be 1 to indicate the end of this
field. The MSB of the first octet is used to indicate whether the
frame is a unicast or a multicast frame.
In the case of an IPv6 multicast, the MSB of the first octet is 1 to
indicate that the frame is multicast. As described above, the LSB of
the first octet is 0 and the LSB of the second octet is 1. The other
13 bits of the address field must contain the lowest-order 13 bits of
the IPv6 multicast address. Figure 3 shows the address field of the
MAPOS 16 frame header in the case of an IPv6 multicast, where D(1)
through D(13) represent the lowest-order 13 bits of the IPv6
multicast address. Exceptions arise when these 13 bits are either
all zeros or all ones. In these cases, the address field should be
0xFEFD (hexadecimal).
MSB LSB
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
|1|D(13)-D(8) |0| D(7)-D(1) |1|
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^ ^
| | |
| | +-- EA bit (always 1)
| +-- EA bit (always 0)
1 (multicast)
Figure 3. Address mapping in multicasting (MAPOS 16).
<span class="grey">Ogura, et. al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3572">RFC 3572</a> IPv6 over MAPOS July 2003</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Interface Identifier</span>
This section specifies the method of forming the interface identifier
[<a href="#ref-7" title=""Internet Protocol Version 6 (IPv6) Addressing Architecture"">7</a>].
A node that has one or more MAPOS interfaces must create one or more
EUI-64 [<a href="#ref-8" title=""Guidelines of 64-bit Global Identifier (EUI-64) Registration Authority"">8</a>] based interface identifiers. Here, it should be noted
that deriving interface identifiers from HDLC addresses of MAPOS
interfaces is undesirable for the following reasons.
1. When a node is connected to a frame switch, an HDLC address is
assigned to the interface of the node from the frame switch via
NSP [<a href="#ref-6" title=""A MAPOS version 1 Extension - Node Switch Protocol"">6</a>]. (In the remainder of this document, the term "MAPOS
address" is used to refer to the address.) The value of the MAPOS
address assigned to the interface depends on the combination of
the switch number of the frame switch and the port number of the
frame switch to which the interface is connected. The switch
number is required to be unique only within a MAPOS multi-switch
environment [<a href="#ref-6" title=""A MAPOS version 1 Extension - Node Switch Protocol"">6</a>]; that is, there can be frame switches that have
the same switch number in different MAPOS multi-switch environment
separated by IP routers. Therefore, the uniqueness of a MAPOS
address is guaranteed only within a MAPOS multi-switch
environment.
Furthermore, if an implementation ensures that the link between
the interface of the node and the port of the frame switch is
hot-swappable, the port number of the frame switch or the frame
switch connected to the interface of the node can be changed, so
the MAPOS address assigned to the interface can also be changed
without performing a system re-start of the node.
In short, the global uniqueness of a MAPOS address is not
guaranteed, and a MAPOS address is not a built-in address but can
be changed without performing a system re-start. Thus, if an
interface identifier were derived from a MAPOS address, it could
also be changed without a system re-start. This would not follow
the recommendation in [<a href="#ref-7" title=""Internet Protocol Version 6 (IPv6) Addressing Architecture"">7</a>].
2. In the case of a point-to-point connection between two nodes, the
same MAPOS address is assigned to each interface. Specifically,
in the case of MAPOS version 1, the assigned address is 0x03 [<a href="#ref-6" title=""A MAPOS version 1 Extension - Node Switch Protocol"">6</a>],
and in the case of MAPOS 16, the assigned address is 0x0003 [<a href="#ref-2" title=""MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing"">2</a>].
It is not easy to achieve link-locality of the interface
identifier in a strict manner using the same Link-layer address.
For the above reasons, nodes with MAPOS interfaces must not derive
their interface identifiers from their MAPOS addresses.
<span class="grey">Ogura, et. al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3572">RFC 3572</a> IPv6 over MAPOS July 2003</span>
The following are methods of forming an interface identifier in
the order of preference. These are almost the same as the methods
described in [<a href="#ref-9" title=""IP Version 6 over PPP"">9</a>] except that a MAPOS address must not be used as a
source of uniqueness when an IEEE global identifier is
unavailable.
1) If an IEEE global identifier (EUI-48 or EUI-64) is available
anywhere on the node, it should be used to construct the interface
identifier due to its uniqueness. When extracting an IEEE global
identifier from another device on the node, care should be taken
to ensure that the extracted identifier is presented in canonical
ordering [<a href="#ref-10" title=""A Caution On The Canonical Ordering Of Link-Layer Addresses"">10</a>].
The only transformation from an EUI-64 identifier is to invert the
"u" bit (universal/local bit in IEEE EUI-64 terminology). For
example, for a globally unique EUI-64 identifier as shown in
Figure 4:
MSB LSB
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+----------------+
Figure 4. Globally unique EUI-64 identifier.
where "c" are the bits of the assigned company_id, "0" is the
value of the universal/local bit to indicate global scope, "g" is
the group/individual bit, and "e" are the bits of the extension
identifier, the IPv6 interface identifier would be as shown in
Figure 5. The only change is inverting the value of the
universal/local bit.
MSB LSB
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+----------------+
Figure 5. IPv6 interface identifier derived from a globally unique
EUI-64 identifier.
In the case of an EUI-48 identifier, it is first converted to the
EUI-64 format by inserting two octets, with hexadecimal values of
0xFF and 0xFE, in the middle of the 48-bit MAC (between the
company_id and extension-identifier portions of the EUI-48 value).
<span class="grey">Ogura, et. al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3572">RFC 3572</a> IPv6 over MAPOS July 2003</span>
For example, for a globally unique 48-bit EUI-48 identifier as
shown in Figure 6:
MSB LSB
|0 1|1 3|3 4|
|0 5|6 1|2 7|
+----------------+----------------+----------------+
|cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+
Figure 6. Globally unique EUI-48 identifier.
where "c" are the bits of the assigned company_id, "0" is the
value of the universal/local bit to indicate global scope, "g" is
the group/individual bit, and "e" are the bits of the extension
identifier, the IPv6 interface identifier would be as shown in
Figure 7.
MSB LSB
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|cccccccc11111111|11111110eeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+----------------+
Figure 7. IPv6 interface identifier derived from a globally unique
EUI-48 identifier.
2) If an IEEE global identifier is not available, a different source
of uniqueness should be used. Suggested sources of uniqueness
include machine serial numbers, etc. MAPOS addresses must not be
used.
In this case, the "u" bit of the interface identifier must be set
to 0.
3) If a good source of uniqueness cannot be found, it is recommended
that a random number be generated. In this case the "u" bit of
the interface identifier must be set to 0.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Duplicate Address Detection</span>
Immediately after the system start-up, the MAPOS address has not yet
been assigned to a MAPOS interface. The assignment is not completed
until the adjacent frame switch, or adjacent node in the case of a
point-to-point connection between two nodes, has delivered the MAPOS
address to the interface via NSP [<a href="#ref-6" title=""A MAPOS version 1 Extension - Node Switch Protocol"">6</a>]. Until then, no data
transmission can be performed on the interface. Thus, a node must
<span class="grey">Ogura, et. al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3572">RFC 3572</a> IPv6 over MAPOS July 2003</span>
conduct duplicate address detection [<a href="#ref-11" title=""IPv6 Stateless Address Autoconfiguration"">11</a>] on all unicast addresses of
MAPOS interfaces after the MAPOS address assignment has been
completed by NSP.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Source/Target Link-layer Address Option</span>
As specified in [<a href="#ref-5" title=""Neighbor Discovery for IP Version 6 (IPv6)"">5</a>], the Source/Target Link-layer Address option is
one of the options included in Neighbor Discovery messages. In [<a href="#ref-5" title=""Neighbor Discovery for IP Version 6 (IPv6)"">5</a>],
the length of the Source/Target Link-layer Address option field is
specified in units of 8 octets. However, in the case of MAPOS, the
length of the address field is 2 octets (MAPOS 16) or 1 octet (MAPOS
version 1)[<a href="#ref-1" title=""MAPOS - Multiple Access protocol over SONET/SDH Version 1"">1</a>][2]. Thus, if the exact form of the address field is
embedded in the Link-layer Address field of the Source/Target Link-
layer Address option field, the total length of the option field is 4
octets (MAPOS 16) or 3 octets (MAPOS version 1), both of which are
shorter than 8 octets.
For the above reason, in the case of MAPOS, the Link-layer Address
field of the Source/Target Link-layer Address option must be extended
with zeros in order to extend the length of the option field to 8
octets, and the Length field must be set to 1 as shown below.
MAPOS version 1:
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 | All 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All 0 | Address | All 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type: 1 for Source link-layer address.
2 for Target link-layer address.
Length: 1 (in units of 8 octets).
Address: MAPOS version 1 8-bit address.
Figure 8. Format of the Source/Target Link-layer Address option
field (MAPOS version 1).
<span class="grey">Ogura, et. al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3572">RFC 3572</a> IPv6 over MAPOS July 2003</span>
MAPOS 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | All 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-layer Address | All 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type: 1 for Source link-layer address.
2 for Target link-layer address.
Length: 1 (in units of 8 octets).
Link-layer Address: MAPOS 16 16-bit address.
Figure 9. Format of the Source/Target Link-layer Address option
field (MAPOS 16).
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
In MAPOS, a link-layer address (MAPOS address) is assigned to a
network interface by a frame switch via NSP; unlike other link-layer
protocols such as Ethernet that use a built-in address on a network
interface. Security considerations derived from this are described
in 6.1 and 6.2. Because there is no link-layer security in MAPOS,
the same security considerations as those of other link-layer
protocols would be applied to other points.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Issues concerning Link-layer Addresses</span>
<span class="h4"><a class="selflink" id="section-6.1.1" href="#section-6.1.1">6.1.1</a>. Protection against fraudulent reception of traffic</span>
In MAPOS, a MAPOS address is assigned by a frame switch, and it
consists of the switch number and the port number of the switch to
which the network interface is connected. (In the case of a point-
to-point connection between two nodes, a fixed address is assigned to
their network interfaces.) This brings the following advantages.
1. The value of the MAPOS address of a MAPOS network interface
indicates the location of the interface in the MAPOS network. In
other words, the value itself of the destination address of a
MAPOS frame defines the actual location of the network interface
to which the frame should be finally delivered. Therefore, as
long as MAPOS addresses of network interfaces of nodes that have
<span class="grey">Ogura, et. al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3572">RFC 3572</a> IPv6 over MAPOS July 2003</span>
been connected to the network through proper administrative
process are held and frames are delivered only to those addresses,
other nodes cannot receive frames unless their network interfaces
are connected to the same ports of frame switches as those to
which network interfaces of properly administered nodes are
connected. This makes fraudulent reception of traffic difficult.
2. In the case where MAPOS addresses are not administered as
mentioned above, it is possible that a malicious node could hijack
traffic by spoofing its IPv6 address in a response to an IPv6
Neighbor Discovery. Even in this case, the node must advertise
the true MAPOS address of its network interface in the response so
that it can receive successive frames. This makes it easy to
pinpoint the location of the host.
<span class="h4"><a class="selflink" id="section-6.1.2" href="#section-6.1.2">6.1.2</a>. Protection against improper traffic</span>
A MAPOS frame does not have a field for including its sender's
address. Therefore, in the case where a node sends one-way improper
traffic maliciously or accidentally, there is no way to obtain the
sender's MAPOS address from the traffic and this leads to difficulty
in identifying the node (because source IP addresses might be
forged).
An effective way to alleviate the difficulty is to moderate the size
of MAPOS multi-switch environment [<a href="#ref-6" title=""A MAPOS version 1 Extension - Node Switch Protocol"">6</a>]. A common approach is to
separate it using IP routers. This makes it easy to identify the
node sending improper traffic within the multi-switch environment.
To secure the environment against improper traffic from outside it,
boundary IP routers need to block it using packet filtering based on
IP layer information.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Uniqueness of Interface Identifiers</span>
Global uniqueness of a MAPOS address is not guaranteed, and a MAPOS
address is not a built-in address but can be changed without
performing a system re-start if an implementation ensures that the
link between the network interface of the node and the port of the
frame switch is hot-swappable. Thus, an interface identifier must
not be derived from a MAPOS address in order to ensure that the
interface identifier is not changed without a system re-start.
As a consequence, in IP Version 6 over MAPOS, the existence of
network interfaces other than MAPOS that have IEEE global identifier
based addresses has great importance in creating interface
identifiers. However, it may be common for there to be no such
interfaces on a node, so a different source of uniqueness must be
used. Therefore, sufficient care should be taken to prevent
<span class="grey">Ogura, et. al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3572">RFC 3572</a> IPv6 over MAPOS July 2003</span>
duplication of interface identifiers. At present, there is no
protection against duplication through accident or forgery.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
[<a id="ref-1">1</a>] Murakami, K. and M. Maruyama, "MAPOS - Multiple Access protocol
over SONET/SDH Version 1", <a href="./rfc2171">RFC 2171</a>, June 1997.
[<a id="ref-2">2</a>] Murakami, K. and M. Maruyama, "MAPOS 16 - Multiple Access
Protocol over SONET/SDH with 16 Bit Addressing", <a href="./rfc2175">RFC 2175</a>, June
1997.
[<a id="ref-3">3</a>] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51, <a href="./rfc1662">RFC 1662</a>,
July 1994.
[<a id="ref-4">4</a>] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", <a href="./rfc2460">RFC 2460</a>, December 1998.
[<a id="ref-5">5</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-6">6</a>] Murakami, K. and M. Maruyama, "A MAPOS version 1 Extension -
Node Switch Protocol", <a href="./rfc2173">RFC 2173</a>, June 1997.
[<a id="ref-7">7</a>] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", <a href="./rfc3513">RFC 3513</a>, April 2003.
[<a id="ref-8">8</a>] IEEE, "Guidelines of 64-bit Global Identifier (EUI-64)
Registration Authority",
<a href="http://standards.ieee.org/db/oui/tutorials/EUI64.html">http://standards.ieee.org/db/oui/tutorials/EUI64.html</a>, March
1997.
[<a id="ref-9">9</a>] Haskin, D. and E. Allen, "IP Version 6 over PPP", <a href="./rfc2472">RFC 2472</a>,
December 1998.
[<a id="ref-10">10</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-11">11</a>] Thompson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", <a href="./rfc2462">RFC 2462</a>, December 1998.
<span class="grey">Ogura, et. al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3572">RFC 3572</a> IPv6 over MAPOS July 2003</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Authors' Addresses</span>
Tsuyoshi Ogura
NTT Network Innovation Laboratories
3-9-11, Midori-cho
Musashino-shi
Tokyo 180-8585, Japan
EMail: ogura@core.ecl.net
Mitsuru Maruyama
NTT Network Innovation Laboratories
3-9-11, Midori-cho
Musashino-shi
Tokyo 180-8585, Japan
EMail: mitsuru@core.ecl.net
Toshiaki Yoshida
Werk Mikro Systems
250-1, Mikajiri
Kumagaya
Saitama 360-0843, Japan
EMail: yoshida@peta.arch.ecl.net
<span class="grey">Ogura, et. al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc3572">RFC 3572</a> IPv6 over MAPOS July 2003</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Full Copyright Statement</span>
Copyright (C) The Internet Society (2003). 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 assignees.
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.
Ogura, et. al. Informational [Page 14]
</pre>
|
