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
|
<pre>Network Working Group L. Berger
Request for Comments: 5250 LabN
Obsoletes: <a href="./rfc2370">2370</a> I. Bryskin
Category: Standards Track Adva
A. Zinin
Alcatel-Lucent
R. Coltun
Acoustra Productions
July 2008
<span class="h1">The OSPF Opaque LSA Option</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.
Abstract
This document defines enhancements to the OSPF protocol to support a
new class of link state advertisements (LSAs) called Opaque LSAs.
Opaque LSAs provide a generalized mechanism to allow for the future
extensibility of OSPF. Opaque LSAs consist of a standard LSA header
followed by application-specific information. The information field
may be used directly by OSPF or by other applications. Standard OSPF
link-state database flooding mechanisms are used to distribute Opaque
LSAs to all or some limited portion of the OSPF topology.
This document replaces <a href="./rfc2370">RFC 2370</a> and adds to it a mechanism to enable
an OSPF router to validate Autonomous System (AS)-scope Opaque LSAs
originated outside of the router's OSPF area.
<span class="grey">Berger, 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="./rfc5250">RFC 5250</a> OSPF Opaque LSA Option July 2008</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Organization of This Document ..............................<a href="#page-3">3</a>
<a href="#section-1.2">1.2</a>. Acknowledgments ............................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Conventions Used in This Document ...............................<a href="#page-4">4</a>
<a href="#section-3">3</a>. The Opaque LSA ..................................................<a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. Flooding Opaque LSAs .......................................<a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. Modifications to the Neighbor State Machine ................<a href="#page-6">6</a>
<a href="#section-4">4</a>. Protocol Data Structures ........................................<a href="#page-7">7</a>
<a href="#section-4.1">4.1</a>. Additions to the OSPF Neighbor Structure ...................<a href="#page-8">8</a>
<a href="#section-5">5</a>. Inter-Area Considerations .......................................<a href="#page-8">8</a>
<a href="#section-6">6</a>. Management Considerations .......................................<a href="#page-9">9</a>
<a href="#section-7">7</a>. Backward Compatibility ..........................................<a href="#page-9">9</a>
<a href="#section-8">8</a>. Security Considerations .........................................<a href="#page-9">9</a>
<a href="#section-9">9</a>. IANA Considerations ............................................<a href="#page-11">11</a>
<a href="#section-10">10</a>. References ....................................................<a href="#page-12">12</a>
<a href="#section-10.1">10.1</a>. Normative References .....................................<a href="#page-12">12</a>
<a href="#section-10.2">10.2</a>. Informative References ...................................<a href="#page-12">12</a>
<a href="#appendix-A">Appendix A</a>. OSPF Data formats .....................................<a href="#page-13">13</a>
<a href="#appendix-A.1">A.1</a>. The Options Field .........................................<a href="#page-13">13</a>
<a href="#appendix-A.2">A.2</a>. The Opaque LSA ............................................<a href="#page-14">14</a>
<span class="grey">Berger, 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="./rfc5250">RFC 5250</a> OSPF Opaque LSA Option July 2008</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Over the last several years, the OSPF routing protocol [<a href="#ref-OSPF" title=""OSPF Version 2"">OSPF</a>] has
been widely deployed throughout the Internet. As a result of this
deployment and the evolution of networking technology, OSPF has been
extended to support many options; this evolution will obviously
continue.
This document defines enhancements to the OSPF protocol to support a
new class of link state advertisements (LSAs) called Opaque LSAs.
Opaque LSAs provide a generalized mechanism to allow for the future
extensibility of OSPF. The information contained in Opaque LSAs may
be used directly by OSPF or indirectly by some application wishing to
distribute information throughout the OSPF domain. The exact use of
Opaque LSAs is beyond the scope of this document.
Opaque LSAs consist of a standard LSA header followed by a 32-bit
aligned application-specific information field. Like any other LSA,
the Opaque LSA uses the link-state database distribution mechanism
for flooding this information throughout the topology. The link-
state type field of the Opaque LSA identifies the LSA's range of
topological distribution. This range is referred to as the flooding
scope.
It is envisioned that an implementation of the Opaque option provides
an application interface for 1) encapsulating application-specific
information in a specific Opaque type, 2) sending and receiving
application-specific information, and 3) if required, informing the
application of the change in validity of previously received
information when topological changes are detected.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Organization of This Document</span>
This document first defines the three types of Opaque LSAs followed
by a description of OSPF packet processing. The packet processing
sections include modifications to the flooding procedure and to the
neighbor state machine. <a href="#appendix-A">Appendix A</a> then gives the packet formats.
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Acknowledgments</span>
We would like to thank Acee Lindem for his detailed review and useful
feedback. The handling of AS-scope Opaque LSAs described in this
document is taken from "Validation of OSPF AS-scope opaque LSAs"
(April 2006).
<span class="grey">Berger, 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="./rfc5250">RFC 5250</a> OSPF Opaque LSA Option July 2008</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions Used in This Document</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to indicate requirements levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. The Opaque LSA</span>
Opaque LSAs are types 9, 10, and 11 link state advertisements.
Opaque LSAs consist of a standard LSA header followed by a 32-bit
aligned application-specific information field. Standard link-state
database flooding mechanisms are used for distribution of Opaque
LSAs. The range of topological distribution (i.e., the flooding
scope) of an Opaque LSA is identified by its link-state type. This
section documents the flooding of Opaque LSAs.
The flooding scope associated with each Opaque link-state type is
defined as follows.
o Link-state type-9 denotes a link-local scope. Type-9 Opaque LSAs
are not flooded beyond the local (sub)network.
o Link-state type-10 denotes an area-local scope. Type-10 Opaque
LSAs are not flooded beyond the borders of their associated area.
o Link-state type-11 denotes that the LSA is flooded throughout the
Autonomous System (AS). The flooding scope of type-11 LSAs are
equivalent to the flooding scope of AS-External (type-5) LSAs.
Specifically, type-11 Opaque LSAs are 1) flooded throughout all
transit areas, 2) not flooded into stub areas or Not-So-Stubby
Areas (NSSAs), see [<a href="#ref-NSSA" title=""The OSPF Not-So-Stubby Area (NSSA) Option"">NSSA</a>], from the backbone, and 3) not
originated by routers into their connected stub areas or NSSAs.
As with type-5 LSAs, if a type-11 Opaque LSA is received in a stub
area or NSSA from a neighboring router within the stub area or
NSSA, the LSA is rejected.
The link-state ID of the Opaque LSA is divided into an Opaque type
field (the first 8 bits) and a type-specific ID (the remaining 24
bits). The packet format of the Opaque LSA is given in <a href="#appendix-A">Appendix A</a>.
<a href="#section-7">Section 7</a> describes Opaque type allocation and assignment.
The responsibility for proper handling of the Opaque LSA's flooding
scope is placed on both the sender and receiver of the LSA. The
receiver must always store a valid received Opaque LSA in its link-
state database. The receiver must not accept Opaque LSAs that
violate the flooding scope (e.g., a type-11 (domain-wide) Opaque LSA
<span class="grey">Berger, 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="./rfc5250">RFC 5250</a> OSPF Opaque LSA Option July 2008</span>
is not accepted in a stub area or NSSA). The flooding scope affects
both the synchronization of the link-state database and the flooding
procedure.
The following describes the modifications to these procedures that
are necessary to insure conformance to the Opaque LSA's Scoping
Rules.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Flooding Opaque LSAs</span>
The flooding of Opaque LSAs MUST follow the rules of flooding scope
as specified in this section. Section 13 of [<a href="#ref-OSPF" title=""OSPF Version 2"">OSPF</a>] describes the
OSPF flooding procedure. Those procedures MUST be followed as
defined except where modified in this section. The following
describes the Opaque LSA's type-specific flooding restrictions.
o If the Opaque LSA is type-9 (the flooding scope is link-local) and
the interface that the LSA was received on is not the same as the
target interface (e.g., the interface associated with a particular
target neighbor), the Opaque LSA MUST be discarded and not
acknowledged. An implementation SHOULD keep track of the IP
interface associated with each Opaque LSA having a link-local
flooding scope.
o If the Opaque LSA is type-10 (the flooding scope is area-local)
and the area associated with the Opaque LSA (as identified during
origination or from a received LSA's associated OSPF packet
header) is not the same as the area associated with the target
interface, the Opaque LSA MUST be discarded and not acknowledged.
An implementation SHOULD keep track of the OSPF area associated
with each Opaque LSA having an area-local flooding scope.
o If the Opaque LSA is type-11 (the LSA is flooded throughout the
AS) and the target interface is associated with a stub area or
NSSA, the Opaque LSA MUST NOT be flooded out the interface. A
type-11 Opaque LSA that is received on an interface associated
with a stub area or NSSA MUST be discarded and not acknowledged
(the neighboring router has flooded the LSA in error).
When opaque-capable routers and non-opaque-capable OSPF routers are
mixed together in a routing domain, the Opaque LSAs are typically not
flooded to the non-opaque-capable routers. As a general design
principle, optional OSPF advertisements are only flooded to those
routers that understand them.
An opaque-capable router learns of its neighbor's opaque capability
at the beginning of the "Database Exchange Process" (see Section 10.6
of [<a href="#ref-OSPF" title=""OSPF Version 2"">OSPF</a>] regarding receiving Database Description packets from a
<span class="grey">Berger, 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="./rfc5250">RFC 5250</a> OSPF Opaque LSA Option July 2008</span>
neighbor in state ExStart). A neighbor is opaque-capable if and only
if it sets the O-bit in the Options field of its Database Description
packets; the O-bit SHOULD NOT be set and MUST be ignored when
received in packets other than Database Description packets. Using
the O-bit in OSPF packets other than Database Description packets
will result in interoperability issues. The setting of the O-bit is
a "SHOULD NOT" rather than a "MUST NOT" to remain compatible with
earlier specifications.
In the next step of the Database Exchange process, Opaque LSAs are
included in the Database summary list that is sent to the neighbor
(see Sections <a href="#section-3.2">3.2</a> below and 10.3 of [<a href="#ref-OSPF" title=""OSPF Version 2"">OSPF</a>]) when the neighbor is
opaque capable.
When flooding Opaque LSAs to adjacent neighbors, an opaque-capable
router looks at the neighbor's opaque capability. Opaque LSAs are
only flooded to opaque-capable neighbors. To be more precise, in
Section 13.3 of [<a href="#ref-OSPF" title=""OSPF Version 2"">OSPF</a>], Opaque LSAs MUST be placed on the link-state
retransmission lists of opaque-capable neighbors and MUST NOT be
placed on the link-state retransmission lists of non-opaque-capable
neighbors. However, when sending Link State Update packets as
multicasts, a non-opaque-capable neighbor may (inadvertently) receive
Opaque LSAs. The non-opaque-capable router will then simply discard
the LSA (see Section 13 of [<a href="#ref-OSPF" title=""OSPF Version 2"">OSPF</a>] regarding receiving LSAs having
unknown LS types).
Information contained in received Opaque LSAs SHOULD only be used
when the router originating the LSA is reachable. As mentioned in
[<a href="#ref-OSPFv3" title=""OSPF for IPv6"">OSPFv3</a>], reachability validation MAY be done less frequently than
every SPF calculation. Additionally, routers processing received
Opaque LSAs MAY choose to give priority to processing base OSPF LSA
types over Opaque LSA types.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Modifications to the Neighbor State Machine</span>
The state machine as it exists in Section 10.3 of [<a href="#ref-OSPF" title=""OSPF Version 2"">OSPF</a>] remains
unchanged except for the action associated with State: ExStart,
Event: NegotiationDone, which is where the Database summary list is
built. To incorporate the Opaque LSA in OSPF, this action is changed
to the following.
State(s): ExStart
Event: NegotiationDone
<span class="grey">Berger, 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="./rfc5250">RFC 5250</a> OSPF Opaque LSA Option July 2008</span>
New state: Exchange
Action: The router MUST list the contents of its entire area
link-state database in the neighbor Database summary
list. The area link-state database consists of the
Router LSAs, Network LSAs, Summary LSAs, type-9 Opaque
LSAs, and type-10 Opaque LSAs contained in the area
structure, along with AS External and type-11 Opaque LSAs
contained in the global structure. AS External and
type-11 Opaque LSAs MUST be omitted from a virtual
neighbor's Database summary list. AS External LSAs and
type-11 Opaque LSAs MUST be omitted from the Database
summary list if the area has been configured as a stub
area or NSSA (see Section 3.6 of [<a href="#ref-OSPF" title=""OSPF Version 2"">OSPF</a>]).
Type-9 Opaque LSAs MUST be omitted from the Database
summary list if the interface associated with the
neighbor is not the interface associated with the Opaque
LSA (as noted upon reception).
Any advertisement whose age is equal to MaxAge MUST be
omitted from the Database summary list. It MUST instead
be added to the neighbor's link-state retransmission
list. A summary of the Database summary list will be
sent to the neighbor in Database Description packets.
Only one Database Description Packet is allowed to be
outstanding at any one time. For more detail on the
sending and receiving of Database Description packets,
see Sections <a href="#section-10.6">10.6</a> and <a href="#section-10.8">10.8</a> of [<a href="#ref-OSPF" title=""OSPF Version 2"">OSPF</a>].
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Protocol Data Structures</span>
The Opaque option is described herein in terms of its operation on
various protocol data structures. These data structures are included
for explanatory uses only. They are not intended to constrain an
implementation. In addition to the data structures listed below,
this specification references the various data structures (e.g., OSPF
neighbors) defined in [<a href="#ref-OSPF" title=""OSPF Version 2"">OSPF</a>].
In an OSPF router, the following item is added to the list of global
OSPF data structures described in Section 5 of [<a href="#ref-OSPF" title=""OSPF Version 2"">OSPF</a>]:
o Opaque capability. Indicates whether the router is running the
Opaque option (i.e., capable of storing Opaque LSAs). Such a
router will continue to interoperate with non-opaque-capable OSPF
routers.
<span class="grey">Berger, 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="./rfc5250">RFC 5250</a> OSPF Opaque LSA Option July 2008</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Additions to the OSPF Neighbor Structure</span>
The OSPF neighbor structure is defined in Section 10 of [<a href="#ref-OSPF" title=""OSPF Version 2"">OSPF</a>]. In
an opaque-capable router, the following items are added to the OSPF
neighbor structure:
o Neighbor Options. This field was already defined in the OSPF
specification. However, in opaque-capable routers, there is a new
option that indicates the neighbor's Opaque capability. This new
option is learned in the Database Exchange process through
reception of the neighbor's Database Description packets and
determines whether Opaque LSAs are flooded to the neighbor. For a
more detailed explanation of the flooding of the Opaque LSA, see
<a href="#section-3">Section 3</a> of this document.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Inter-Area Considerations</span>
As defined above, link-state type-11 Opaque LSAs are flooded
throughout the Autonomous System (AS). One issue related to such
AS-scoped Opaque LSAs is that there must be a way for OSPF routers in
remote areas to check availability of the LSA originator.
Specifically, if an OSPF router originates a type-11 LSA and, after
that, goes out of service, OSPF routers located outside of the
originator's OSPF area have no way of detecting this fact and may use
the stale information for a considerable period of time (up to 60
minutes). This could prove to be suboptimal for some applications
and may result in others not functioning.
Type-9 Opaque LSAs and type-10 Opaque LSAs do not have this problem
as a receiving router can detect if the advertising router is
reachable within the LSA's respective flooding scope. In the case of
type-9 LSAs, the originating router must be an OSPF neighbor in
Exchange state or greater. In the case of type-10 Opaque LSAs, the
intra-area SPF calculation will determine the advertising router's
reachability.
There is a parallel issue in OSPF for the AS-scoped AS External LSAs
(type-5 LSAs). OSPF addresses this by using AS border information
advertised in AS boundary router (ASBR) Summary LSAs (type-4 LSAs);
see Section 16.4 of [<a href="#ref-OSPF" title=""OSPF Version 2"">OSPF</a>]. This same mechanism is reused by this
document for type-11 Opaque LSAs.
To enable OSPF routers in remote areas to check availability of the
originator of link-state type-11 Opaque LSAs, the originators
advertise themselves as ASBRs. This will enable routers to track the
reachability of the LSA originator either directly via the SPF
calculation (for routers in the same area) or indirectly via type-4
LSAs originated by ABRs (for routers in other areas). It is
<span class="grey">Berger, 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="./rfc5250">RFC 5250</a> OSPF Opaque LSA Option July 2008</span>
important to note that per [<a href="#ref-OSPF" title=""OSPF Version 2"">OSPF</a>], this solution does not apply to
OSPF stub areas or NSSAs as AS-scoped Opaque LSAs are not flooded
into these area types.
The procedures related to inter-area Opaque LSAs are as follows:
(1) An OSPF router that is configured to originate AS-scope opaque
LSAs will advertise itself as an ASBR and MUST follow the
requirements related to setting of the Options field E-bit in
OSPF LSA headers as specified in [<a href="#ref-OSPF" title=""OSPF Version 2"">OSPF</a>].
(2) When processing a received type-11 Opaque LSA, the router MUST
look up the routing table entries (potentially one per attached
area) for the ASBR that originated the LSA. If no entries exist
for the ASBR (i.e., the ASBR is unreachable), the router MUST do
nothing with this LSA. It also MUST discontinue using all Opaque
LSAs injected into the network by the same originator whenever it
is detected that the originator is unreachable.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Management Considerations</span>
The updated OSPF MIB, [<a href="./rfc4750" title=""OSPF Version 2 Management Information Base"">RFC4750</a>], provides explicit support for Opaque
LSAs and SHOULD be used to support implementations of this document.
See <a href="./rfc4750#section-12.3">Section 12.3 of [RFC4750]</a> for details. In addition to that
section, implementations supporting [<a href="./rfc4750" title=""OSPF Version 2 Management Information Base"">RFC4750</a>] will also include
Opaque LSAs in all appropriate generic LSA objects, e.g.,
ospfOriginateNewLsas and ospfLsdbTable.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Backward Compatibility</span>
The solution proposed in this document introduces no interoperability
issues. In the case that a non-opaque-capable neighbor receives
Opaque LSAs, per [<a href="#ref-OSPF" title=""OSPF Version 2"">OSPF</a>], the non-opaque-capable router will simply
discard the LSA.
Note that OSPF routers that implement [<a href="./rfc2370" title=""The OSPF Opaque LSA Option"">RFC2370</a>] will continue using
stale type-11 LSAs even when the LSA originator implements the
inter-area procedures described in <a href="#section-6">Section 6</a> of this document.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
There are two types of issues that need be addressed when looking at
protecting routing protocols from misconfigurations and malicious
attacks. The first is authentication and certification of routing
protocol information. The second is denial-of-service attacks
resulting from repetitive origination of the same router
advertisement or origination of a large number of distinct
advertisements resulting in database overflow. Note that both of
<span class="grey">Berger, 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="./rfc5250">RFC 5250</a> OSPF Opaque LSA Option July 2008</span>
these concerns exist independently of a router's support for the
Opaque option.
To address the authentication concerns, OSPF protocol exchanges are
authenticated. OSPF supports multiple types of authentication; the
type of authentication in use can be configured on a per-network-
segment basis. One of OSPF's authentication types, namely the
Cryptographic authentication option, is believed to be secure against
passive attacks and provide significant protection against active
attacks. When using the Cryptographic authentication option, each
router appends a "message digest" to its transmitted OSPF packets.
Receivers then use the shared secret key and received digest to
verify that each received OSPF packet is authentic.
The quality of the security provided by the Cryptographic
authentication option depends completely on the strength of the
message digest algorithm (MD5 is currently the only message digest
algorithm specified), the strength of the key being used, and the
correct implementation of the security mechanism in all communicating
OSPF implementations. It also requires that all parties maintain the
secrecy of the shared secret key. None of the standard OSPF
authentication types provide confidentiality. Nor do they protect
against traffic analysis. For more information on the standard OSPF
security mechanisms, see Sections <a href="#section-8.1">8.1</a>, <a href="#section-8.2">8.2</a>, and <a href="#appendix-D">Appendix D</a> of [<a href="#ref-OSPF" title=""OSPF Version 2"">OSPF</a>].
Repetitive origination of advertisements is addressed by OSPF by
mandating a limit on the frequency that new instances of any
particular LSA can be originated and accepted during the flooding
procedure. The frequency at which new LSA instances may be
originated is set equal to once every MinLSInterval seconds, whose
value is 5 seconds (see Section 12.4 of [<a href="#ref-OSPF" title=""OSPF Version 2"">OSPF</a>]). The frequency at
which new LSA instances are accepted during flooding is once every
MinLSArrival seconds, whose value is set to 1 (see <a href="#section-13">Section 13</a>,
<a href="#appendix-B">Appendix B</a>, and G.5 of [<a href="#ref-OSPF" title=""OSPF Version 2"">OSPF</a>]).
Proper operation of the OSPF protocol requires that all OSPF routers
maintain an identical copy of the OSPF link-state database. However,
when the size of the link-state database becomes very large, some
routers may be unable to keep the entire database due to resource
shortages; we term this "database overflow". When database overflow
is anticipated, the routers with limited resources can be
accommodated by configuring OSPF stub areas and NSSAs. [<a href="#ref-OVERFLOW" title=""OSPF Database Overflow"">OVERFLOW</a>]
details a way of gracefully handling unanticipated database
overflows.
<span class="grey">Berger, 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="./rfc5250">RFC 5250</a> OSPF Opaque LSA Option July 2008</span>
In the case of type-11 Opaque LSAs, this document reuses an ASBR
tracking mechanism that is already employed in basic OSPF for type-5
LSAs. Therefore, applying it to type-11 Opaque LSAs does not create
any threats that are not already known for type-5 LSAs.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. IANA Considerations</span>
This document updates the requirements for the OSPF Opaque LSA type
registry. Three following changes have been made:
1. References to [<a href="./rfc2370" title=""The OSPF Opaque LSA Option"">RFC2370</a>] have been replaced with references to this
document.
2. The Opaque type values in the range of 128-255 have been reserved
for "Private Use" as defined in [<a href="./rfc5226" title="">RFC5226</a>].
3. The reference for Opaque type registry value 1, Traffic
Engineering LSA, has been updated to [<a href="./rfc3630" title=""Traffic Engineering (TE) Extensions to OSPF Version 2"">RFC3630</a>].
The registry now reads:
Open Shortest Path First (OSPF) Opaque Link-State
Advertisements (LSA) Option Types
Registries included below:
- Opaque Link-State Advertisements (LSA) Option Types
Registry Name: Opaque Link-State Advertisements (LSA) Option Types
Reference: [<a href="./rfc5250">RFC5250</a>]
Range Registration Procedures Notes
-------- ------------------------------------------ --------
0-127 IETF Consensus
128-255 Private Use
Registry:
Value Opaque Type Reference
------- ------------------------------------------ ---------
1 Traffic Engineering LSA [<a href="./rfc3630" title=""Traffic Engineering (TE) Extensions to OSPF Version 2"">RFC3630</a>]
2 Sycamore Optical Topology Descriptions [Moy]
3 grace-LSA [<a href="./rfc3623">RFC3623</a>]
4 Router Information (RI) [<a href="./rfc4970">RFC4970</a>]
5-127 Unassigned
128-255 Private Use
<span class="grey">Berger, 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="./rfc5250">RFC 5250</a> OSPF Opaque LSA Option July 2008</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-DEMD">DEMD</a>] Moy, J., "Extending OSPF to Support Demand Circuits", <a href="./rfc1793">RFC</a>
<a href="./rfc1793">1793</a>, April 1995.
[<a id="ref-OSPF">OSPF</a>] Moy, J., "OSPF Version 2", STD 54, <a href="./rfc2328">RFC 2328</a>, April 1998.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC4750">RFC4750</a>] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed.,
Coltun, R., and F. Baker, "OSPF Version 2 Management
Information Base", <a href="./rfc4750">RFC 4750</a>, December 2006.
[<a id="ref-RFC5226">RFC5226</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
May 2008.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-MOSPF">MOSPF</a>] Moy, J., "Multicast Extensions to OSPF", <a href="./rfc1584">RFC 1584</a>, March
1994.
[<a id="ref-NSSA">NSSA</a>] Murphy P., "The OSPF Not-So-Stubby Area (NSSA) Option",
<a href="./rfc3101">RFC 3101</a>, January 2003.
[<a id="ref-OSPF-MT">OSPF-MT</a>] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", <a href="./rfc4915">RFC</a>
<a href="./rfc4915">4915</a>, June 2007.
[<a id="ref-OSPFv3">OSPFv3</a>] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, Ed.,
"OSPF for IPv6", Work in Progress, May 2008.
[<a id="ref-OVERFLOW">OVERFLOW</a>] Moy, J., "OSPF Database Overflow", <a href="./rfc1765">RFC 1765</a>, March 1995.
[<a id="ref-RFC2370">RFC2370</a>] Coltun, R., "The OSPF Opaque LSA Option", <a href="./rfc2370">RFC 2370</a>, July
1998.
[<a id="ref-RFC3630">RFC3630</a>] Katz, D., Kompella, K., and D. Yeund, "Traffic Engineering
(TE) Extensions to OSPF Version 2", <a href="./rfc3630">RFC 3630</a>, September
2003.
[<a id="ref-RFC4576">RFC4576</a>] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a
Link State Advertisement (LSA) Options Bit to Prevent
Looping in BGP/MPLS IP Virtual Private Networks (VPNs)",
<a href="./rfc4576">RFC 4576</a>, June 2006.
<span class="grey">Berger, 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="./rfc5250">RFC 5250</a> OSPF Opaque LSA Option July 2008</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. OSPF Data Formats</span>
This appendix describes the format of the Options Field followed by
the packet format of the Opaque LSA.
<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>. The Options Field</span>
The OSPF Options field is present in OSPF Hello packets, Database
Description packets, and all link state advertisements. The Options
field enables OSPF routers to support (or not support) optional
capabilities, and to communicate their capability level to other OSPF
routers. Through this mechanism, routers of differing capabilities
can be mixed within an OSPF routing domain.
When used in Hello packets, the Options field allows a router to
reject a neighbor because of a capability mismatch. Alternatively,
when capabilities are exchanged in Database Description packets a
router can choose not to flood certain link state advertisements to a
neighbor because of its reduced functionality. Lastly, listing
capabilities in link state advertisements allows routers to forward
traffic around reduced functionality routers by excluding them from
parts of the routing table calculation.
All 8 bits of the OSPF Options field have been assigned, although
only the O-bit is described completely by this document. Each bit is
described briefly below. Routers SHOULD reset (i.e., clear)
unrecognized bits in the Options field when sending Hello packets or
Database Description packets and when originating link state
advertisements. Conversely, routers encountering unrecognized Option
bits in received Hello Packets, Database Description packets, or link
state advertisements SHOULD ignore the capability and process the
packet/advertisement normally.
+--------------------------------------+
| DN | O | DC | EA | N/P | MC | E | MT |
+--------------------------------------+
The Options Field
MT-bit
This bit describes the router's multi-topology link-excluding
capability, as described in [<a href="#ref-OSPF-MT" title=""Multi-Topology (MT) Routing in OSPF"">OSPF-MT</a>].
E-bit
This bit describes the way AS-External LSAs are flooded, as
described in Sections <a href="#section-3.6">3.6</a>, <a href="#section-9.5">9.5</a>, <a href="#section-10.8">10.8</a>, and <a href="#section-12.1.2">12.1.2</a> of [<a href="#ref-OSPF" title=""OSPF Version 2"">OSPF</a>].
<span class="grey">Berger, 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="./rfc5250">RFC 5250</a> OSPF Opaque LSA Option July 2008</span>
MC-bit
This bit describes whether IP multicast datagrams are forwarded
according to the specifications in [<a href="#ref-MOSPF" title=""Multicast Extensions to OSPF"">MOSPF</a>].
N/P-bit
This bit describes the handling of Type-7 LSAs, as specified in
[<a href="#ref-NSSA" title=""The OSPF Not-So-Stubby Area (NSSA) Option"">NSSA</a>].
DC-bit
This bit describes the router's handling of demand circuits, as
specified in [<a href="#ref-DEMD" title=""Extending OSPF to Support Demand Circuits"">DEMD</a>].
EA-bit
This bit describes the router's willingness to receive and
forward External-Attributes-LSAs. While defined, the documents
specifying this bit have all expired. The use of this bit may
be deprecated in the future.
O-bit
This bit describes the router's willingness to receive and
forward Opaque LSAs as specified in this document.
DN-bit
This bit is used to prevent looping in BGP/MPLS IP VPNs, as
specified in [<a href="./rfc4576" title=""Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)"">RFC4576</a>].
<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a>. The Opaque LSA</span>
Opaque LSAs are Type 9, 10, and 11 link state advertisements. These
advertisements MAY be used directly by OSPF or indirectly by some
application wishing to distribute information throughout the OSPF
domain. The function of the Opaque LSA option is to provide for
future OSPF extensibility.
Opaque LSAs contain some number of octets (of application-specific
data) padded to 32-bit alignment. Like any other LSA, the Opaque LSA
uses the link-state database distribution mechanism for flooding this
information throughout the topology. However, the Opaque LSA has a
flooding scope associated with it so that the scope of flooding may
be link-local (type-9), area-local (type-10), or the entire OSPF
routing domain (type-11). <a href="#section-3">Section 3</a> of this document describes the
flooding procedures for the Opaque LSA.
<span class="grey">Berger, 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="./rfc5250">RFC 5250</a> OSPF Opaque LSA Option July 2008</span>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 9, 10, or 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type | Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Opaque Information |
+ +
| ... |
Link-State Type
The link-state type of the Opaque LSA identifies the LSA's range
of topological distribution. This range is referred to as the
flooding scope. The following explains the flooding scope of each
of the link-state types.
o A value of 9 denotes a link-local scope. Opaque LSAs with a
link-local scope MUST NOT be flooded beyond the local
(sub)network.
o A value of 10 denotes an area-local scope. Opaque LSAs with an
area-local scope MUST NOT be flooded beyond their area of
origin.
o A value of 11 denotes that the LSA is flooded throughout the
Autonomous System (e.g., has the same scope as type-5 LSAs).
Opaque LSAs with AS-wide scope MUST NOT be flooded into stub
areas or NSSAs.
Syntax of the Opaque LSA's Link-State ID
The link-state ID of the Opaque LSA is divided into an Opaque Type
field (the first 8 bits) and an Opaque ID (the remaining 24 bits).
See <a href="#section-7">section 7</a> of this document for a description of Opaque type
allocation and assignment.
<span class="grey">Berger, 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="./rfc5250">RFC 5250</a> OSPF Opaque LSA Option July 2008</span>
Authors' Addresses
Lou Berger
LabN Consulting, L.L.C.
EMail: lberger@labn.net
Igor Bryskin
ADVA Optical Networking Inc
7926 Jones Branch Drive
Suite 615
McLean, VA 22102
EMail: ibryskin@advaoptical.com
Alex Zinin
Alcatel-Lucent
750D Chai Chee Rd #06-06
Technopark@ChaiChee
Singapore, 469004
EMail: alex.zinin@alcatel-lucent.com
Rob Coltun
Acoustra Productions
3204 Brooklawn Terrace
Chevy Chase, MD 20815
USA
<span class="grey">Berger, 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="./rfc5250">RFC 5250</a> OSPF Opaque LSA Option July 2008</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
Berger, et al. Standards Track [Page 17]
</pre>
|
