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
|
<pre>Network Working Group K. Kompella
Request for Comments: 4940 Juniper Networks
BCP: 130 B. Fenner
Category: Best Current Practice AT&T Labs--Research
June 2007
<span class="h1">IANA Considerations for OSPF</span>
Status of This Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This memo creates a number of OSPF registries and provides guidance
to IANA for assignment of code points within these registries.
<span class="grey">Kompella & Fenner Best Current Practice [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4940">RFC 4940</a> IANA Considerations for OSPF June 2007</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>. Conventions Used in This Document ..........................<a href="#page-4">4</a>
<a href="#section-2">2</a>. OSPF Registries .................................................<a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. OSPFv2 Options .............................................<a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. OSPFv3 Options .............................................<a href="#page-4">4</a>
<a href="#section-2.3">2.3</a>. OSPF Packet Type (Both v2 and v3) ..........................<a href="#page-4">4</a>
<a href="#section-2.3.1">2.3.1</a>. OSPF Authentication Type ............................<a href="#page-5">5</a>
<a href="#section-2.4">2.4</a>. OSPFv2 Link State (LS) Type ................................<a href="#page-5">5</a>
<a href="#section-2.4.1">2.4.1</a>. OSPFv2 Router LSA Link Type .........................<a href="#page-5">5</a>
<a href="#section-2.4.2">2.4.2</a>. OSPFv2 Router Properties ............................<a href="#page-6">6</a>
<a href="#section-2.5">2.5</a>. OSPFv3 LSA Function Code ...................................<a href="#page-6">6</a>
<a href="#section-2.5.1">2.5.1</a>. OSPFv3 Prefix Options ...............................<a href="#page-6">6</a>
<a href="#section-2.5.2">2.5.2</a>. OSPFv3 Router LSA Link Type .........................<a href="#page-6">6</a>
<a href="#section-2.6">2.6</a>. OSPFv2 Opaque LSA Type .....................................<a href="#page-7">7</a>
<a href="#section-2.6.1">2.6.1</a>. OSPFv2 Grace LSA Top Level TLVs .....................<a href="#page-7">7</a>
<a href="#section-3">3</a>. Acknowledgments .................................................<a href="#page-8">8</a>
<a href="#section-4">4</a>. Security Considerations .........................................<a href="#page-8">8</a>
<a href="#section-5">5</a>. IANA Considerations .............................................<a href="#page-8">8</a>
<a href="#section-5.1">5.1</a>. OSPFv2 Options Registry ....................................<a href="#page-8">8</a>
<a href="#section-5.2">5.2</a>. OSPFv3 Options Registry ....................................<a href="#page-8">8</a>
<a href="#section-5.3">5.3</a>. OSPF Packet Type Registry ..................................<a href="#page-9">9</a>
<a href="#section-5.4">5.4</a>. OSPF Authentication Type Registry ..........................<a href="#page-9">9</a>
<a href="#section-5.5">5.5</a>. OSPFv2 Link State Type Registry ............................<a href="#page-9">9</a>
<a href="#section-5.6">5.6</a>. OSPFv2 Router LSA Link Type Registry ......................<a href="#page-10">10</a>
<a href="#section-5.7">5.7</a>. OSPFv2 Router Properties Registry .........................<a href="#page-10">10</a>
<a href="#section-5.8">5.8</a>. OSPFv3 LSA Function Code Registry .........................<a href="#page-11">11</a>
<a href="#section-5.9">5.9</a>. OSPFv3 Prefix Options Registry ............................<a href="#page-12">12</a>
<a href="#section-5.10">5.10</a>. OSPFv3 Router LSA Link Type Registry .....................<a href="#page-12">12</a>
<a href="#section-5.11">5.11</a>. OSPFv2 Opaque LSA Type Registry ..........................<a href="#page-13">13</a>
<a href="#section-5.12">5.12</a>. OSPFv2 Grace LSA Top Level TLV Registry ..................<a href="#page-13">13</a>
<a href="#section-6">6</a>. References .....................................................<a href="#page-13">13</a>
<a href="#section-6.1">6.1</a>. Normative References ......................................<a href="#page-13">13</a>
<a href="#section-6.2">6.2</a>. Informative References ....................................<a href="#page-14">14</a>
<span class="grey">Kompella & Fenner Best Current Practice [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4940">RFC 4940</a> IANA Considerations for OSPF June 2007</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This memo defines various OSPF registries for IANA to set up and
maintain for OSPF code points. In some cases, this memo defines
ranges of code point values within these registries; each such range
has a different assignment policy.
The terms used in describing the assignment policies are as follows:
o Standards Action
o Experimentation
o Vendor Private Use
o Reserved
Standards Action means that assignments in that range MUST only be
made for Standards Track RFCs (as defined in [<a href="./rfc2434" title="">RFC2434</a>]).
Some of the registries defined below reserve a range of values for
Experimentation. For guidelines regarding the use of such values see
[<a href="./rfc3692" title=""Assigning Experimental and Testing Numbers Considered Useful"">RFC3692</a>]. Values from this range MUST NOT be assigned by IANA.
Further guidance on the use of the Experimentation range may be found
in paragraphs 4, 5, and 6 of [<a href="./rfc3692" title=""Assigning Experimental and Testing Numbers Considered Useful"">RFC3692</a>]. An implementation MAY choose
to not support values from the Experimentation range. In such a
case, the protocol data structure with a code point from the
Experimentation range is ignored, unless other protocol machinery
says how to deal with it. "Ignored" in this context means that the
associated data structure is removed from the received packet before
further processing, including flooding.
Values set aside as Vendor Private Use MUST NOT be assigned by IANA.
A protocol data structure whose code point falls in this range MUST
have a disambiguating field identifying the Vendor. This identifier
consists of four octets of the Vendor's SMI (Structure of Management
Information) enterprise code (see [<a href="#ref-ENTERPRISE-NUMBERS">ENTERPRISE-NUMBERS</a>]) in network
byte order; the location of this code must be well-defined per data
structure. An implementation that encounters a Vendor Private code
point SHOULD check whether the enterprise code is one that it
recognizes; if so, the implementation MAY choose to interpret the
code point and data structure. Otherwise, it SHOULD ignore the code
point, unless the protocol machinery says how to deal with the data
structure (as defined in the previous paragraph). This allows
multiple vendor private extensions to coexist in a network.
Values in the Reserved range MUST NOT be assigned until a Standards
Track or Best Common Practices RFC is published defining the
<span class="grey">Kompella & Fenner Best Current Practice [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4940">RFC 4940</a> IANA Considerations for OSPF June 2007</span>
assignment policy for that range. This RFC MUST be the product of
the OSPF Working Group; if the OSPF WG is terminated, then it MUST be
reviewed by an Expert Reviewer designated by the IESG.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</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">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. OSPF Registries</span>
This section lists the various registries for OSPF protocol code
points. Note that some of these are for OSPF, and some are specific
to a particular version of OSPF; also, some registries predate this
memo.
Registries that are specific to one version of OSPF reflect the
version number in the registry name (e.g., OSPFv2 Options). A
registry whose name does not mention a version number applies to both
OSPFv2 and OSPFv3 (e.g., OSPF Packet Type).
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. OSPFv2 Options</span>
(Defined in Section A.2 of [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>], updated in Section A.1 of
[<a href="./rfc2370" title=""The OSPF Opaque LSA Option"">RFC2370</a>]. See also [<a href="./rfc3101" title=""The OSPF Not-So-Stubby Area (NSSA) Option"">RFC3101</a>].)
Assignment policy: Standards Action.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. OSPFv3 Options</span>
(Defined in Section A.2 of [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>])
Assignment policy: Standards Action.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. OSPF Packet Type (Both v2 and v3)</span>
(Defined in Section A.3.1 of [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>])
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-5 | Already assigned |
| 6-127 | Standards Action |
| 128-255 | Reserved |
+---------+--------------------+
<span class="grey">Kompella & Fenner Best Current Practice [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4940">RFC 4940</a> IANA Considerations for OSPF June 2007</span>
<span class="h4"><a class="selflink" id="section-2.3.1" href="#section-2.3.1">2.3.1</a>. OSPF Authentication Type</span>
(Defined in Section A.3.1 of [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>])
(Note: this registry is called "OSPF AUTHENTICATION CODES" by IANA.)
+-------------+-------------------+
| Range | Assignment Policy |
+-------------+-------------------+
| 0-2 | Already assigned |
| 3-247 | Standards Action |
| 248-65519 | Reserved |
| 65520-65535 | Experimentation |
+-------------+-------------------+
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. OSPFv2 Link State (LS) Type</span>
(Defined in Section A.4.1 of [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>])
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-11 | Already assigned |
| 12-127 | Standards Action |
| 128-255 | Reserved |
+---------+--------------------+
If a new LS Type is documented, the documentation MUST say how the
Link State ID is to be filled in, what the flooding scope of the LSA
(Link State Advertisement) is, and how backward compatibility is
maintained.
<span class="h4"><a class="selflink" id="section-2.4.1" href="#section-2.4.1">2.4.1</a>. OSPFv2 Router LSA Link Type</span>
(Defined in Section A.4.2 of [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>])
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-4 | Already assigned |
| 5-127 | Standards Action |
| 128-255 | Reserved |
+---------+--------------------+
There is no range for Vendor Private Use, as there is no space for an
enterprise code to identify the Vendor.
<span class="grey">Kompella & Fenner Best Current Practice [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4940">RFC 4940</a> IANA Considerations for OSPF June 2007</span>
No Experimental range is defined, due to possible backwards
compatibility issues.
If a new Router LSA Link Type is documented, the documentation SHOULD
say how the Link State ID, Link ID, and Link Data fields are to be
filled in, and how backward compatibility is maintained.
<span class="h4"><a class="selflink" id="section-2.4.2" href="#section-2.4.2">2.4.2</a>. OSPFv2 Router Properties</span>
(Defined in Section A.4.2 of [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>], updated in [<a href="./rfc3101" title=""The OSPF Not-So-Stubby Area (NSSA) Option"">RFC3101</a>])
This 8-bit field in the Router LSA is unnamed; it is the field
immediately following the Router LSA length.
Assignment policy: Standards Action.
<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>. OSPFv3 LSA Function Code</span>
This registry is created by [<a href="#ref-OSPF-CAP" title=""Extensions to OSPF for Advertising Optional Router Capabilities"">OSPF-CAP</a>]. This document provides the
values to be populated for values defined in Section A.4.2.1 of
[<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>].
<span class="h4"><a class="selflink" id="section-2.5.1" href="#section-2.5.1">2.5.1</a>. OSPFv3 Prefix Options</span>
(Defined in Section A.4.1.1 of [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>])
Assignment policy: Standards Action.
<span class="h4"><a class="selflink" id="section-2.5.2" href="#section-2.5.2">2.5.2</a>. OSPFv3 Router LSA Link Type</span>
(Defined in Section A.4.3 of [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>])
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-4 | Already assigned |
| 5-127 | Standards Action |
| 128-255 | Reserved |
+---------+--------------------+
There is no range for Vendor Private Use, as there is no space for an
enterprise code to identify the Vendor.
No Experimental range is defined, due to possible backwards
compatibility issues.
<span class="grey">Kompella & Fenner Best Current Practice [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4940">RFC 4940</a> IANA Considerations for OSPF June 2007</span>
<span class="h3"><a class="selflink" id="section-2.6" href="#section-2.6">2.6</a>. OSPFv2 Opaque LSA Type</span>
(Defined in Section A.2 of [<a href="./rfc2370" title=""The OSPF Opaque LSA Option"">RFC2370</a>])
(Note: this registry is called "OSPF Opaque LSA Option" by IANA. See
also [<a href="./rfc3630" title=""Traffic Engineering (TE) Extensions to OSPF Version 2"">RFC3630</a>].)
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-3 | Already assigned |
| 4-127 | Standards Action |
| 128-247 | Reserved |
| 248-251 | Experimentation |
| 252-255 | Vendor Private Use |
+---------+--------------------+
In an OSPFv2 Opaque LSA with Opaque LSA Type in the Vendor Private
Use range, the first four octets of Opaque Information MUST be the
Vendor enterprise code.
A document defining a new Standards Track Opaque LSA with TLVs and
sub-TLVs MUST describe ranges and assignment policies for these TLVs.
<span class="h4"><a class="selflink" id="section-2.6.1" href="#section-2.6.1">2.6.1</a>. OSPFv2 Grace LSA Top Level TLVs</span>
(Defined in <a href="./rfc3623#appendix-A">Appendix A of [RFC3623]</a>)
+-------------+--------------------+
| Range | Assignment Policy |
+-------------+--------------------+
| 0 | Not to be assigned |
| 1-3 | Already assigned |
| 4-255 | Standards Action |
| 256-65519 | Reserved |
| 65520-65527 | Experimentation |
| 65528-65535 | Vendor Private Use |
+-------------+--------------------+
In a Grace LSA, if a top-level TLV has a Type from the Vendor Private
Use range, the Length MUST be at least four, and the first four
octets of the Value field MUST be the Vendor enterprise code.
<span class="grey">Kompella & Fenner Best Current Practice [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4940">RFC 4940</a> IANA Considerations for OSPF June 2007</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Acknowledgments</span>
Many thanks to Adrian Farrel and Acee Lindem for their review and
comments.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
The lack of adequate IANA guidelines may be viewed as an avenue for
Denial of Service attacks on IETF protocols (in this case, OSPFv2 and
OSPFv3), and on the IETF Standards Process in general. This memo
attempts to close this loophole for OSPFv2 and OSPFv3.
Authors contemplating extensions to OSPF SHOULD examine such
extensions carefully, and consider whether new registries are needed,
and if so, allocation policies within each registry.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. IANA Considerations</span>
This document specifies assignment policy for several existing IANA
registries and creates several more.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. OSPFv2 Options Registry</span>
<a href="#section-2.1">Section 2.1</a> defines the policy for allocation of bits from this
registry as "Standards Action". There are only 8 bits in this field,
and 6 are already assigned. The initial registry contents are given
below.
OSPFv2 Options Registry (<a href="#section-2.1">Section 2.1</a>)
Value Description Reference
----- ----------- ---------
0x02 E-bit [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>]
0x04 MC-bit [<a href="./rfc1584" title=""Multicast Extensions to OSPF"">RFC1584</a>]
0x08 N/P-bit [<a href="./rfc3101" title=""The OSPF Not-So-Stubby Area (NSSA) Option"">RFC3101</a>]
0x10 Reserved
0x20 DC-bit [<a href="./rfc1793" title=""Extending OSPF to Support Demand Circuits"">RFC1793</a>]
0x40 O-bit [<a href="./rfc2370" title=""The OSPF Opaque LSA Option"">RFC2370</a>]
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. OSPFv3 Options Registry</span>
<a href="#section-2.2">Section 2.2</a> defines the policy for allocation of bits from this
registry as "Standards Action". There are 24 bits in this field, and
6 are assigned. The initial registry contents are given below.
<span class="grey">Kompella & Fenner Best Current Practice [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4940">RFC 4940</a> IANA Considerations for OSPF June 2007</span>
OSPFv3 Options Registry (<a href="#section-2.2">Section 2.2</a>)
Value Description Reference
-------- ----------- ---------
0x000001 V6-bit [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>]
0x000002 E-bit [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>]
0x000004 MC-bit [<a href="./rfc1584" title=""Multicast Extensions to OSPF"">RFC1584</a>]
0x000008 N-bit [<a href="./rfc3101" title=""The OSPF Not-So-Stubby Area (NSSA) Option"">RFC3101</a>]
0x000010 R-Bit [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>]
0x000020 DC-bit [<a href="./rfc1793" title=""Extending OSPF to Support Demand Circuits"">RFC1793</a>]
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. OSPF Packet Type Registry</span>
<a href="#section-2.3">Section 2.3</a> defines the policy for allocation of values from this
registry for different ranges. The initial registry contents are
given below.
OSPF Packet Type (<a href="#section-2.3">Section 2.3</a>)
Value Description Reference
----- -------------------- ---------
1 Hello [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>]
2 Database Description [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>]
3 Link State Request [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>]
4 Link State Update [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>]
5 Link State Ack [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>]
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. OSPF Authentication Type Registry</span>
This registry already exists at IANA, called "ospf-authentication-
codes". <a href="#section-2.3.1">Section 2.3.1</a> defines the policy for allocation from this
registry for different ranges.
<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>. OSPFv2 Link State Type Registry</span>
<a href="#section-2.4">Section 2.4</a> defines the policy for allocations from this registry for
different ranges. The initial registry contents are given below.
<span class="grey">Kompella & Fenner Best Current Practice [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4940">RFC 4940</a> IANA Considerations for OSPF June 2007</span>
OSPFv2 Link State (LS) Type (<a href="#section-2.4">Section 2.4</a>)
Value Description Reference
----- ------------------------ ---------
1 Router-LSA [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>]
2 Network-LSA [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>]
3 Summary-LSA (IP network) [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>]
4 Summary-LSA (ASBR) [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>]
5 AS-external-LSA [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>]
6 Group-membership-LSA [<a href="./rfc1584" title=""Multicast Extensions to OSPF"">RFC1584</a>]
7 NSSA AS-external LSA [<a href="./rfc3101" title=""The OSPF Not-So-Stubby Area (NSSA) Option"">RFC3101</a>]
8 Reserved
9 Link-local Opaque LSA [<a href="./rfc2370" title=""The OSPF Opaque LSA Option"">RFC2370</a>]
10 Area-local Opaque LSA [<a href="./rfc2370" title=""The OSPF Opaque LSA Option"">RFC2370</a>]
11 Opaque LSA [<a href="./rfc2370" title=""The OSPF Opaque LSA Option"">RFC2370</a>]
<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a>. OSPFv2 Router LSA Link Type Registry</span>
<a href="#section-2.4.1">Section 2.4.1</a> defines the policy for allocations from this registry
for different ranges. The initial registry contents are given below.
OSPFv2 Router LSA Link Type (<a href="#section-2.4.1">Section 2.4.1</a>)
Value Description Reference
----- ------------------------------------------- ---------
1 Point-to-Point connection to another router [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>]
2 Transit Network [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>]
3 Stub Network [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>]
4 Virtual Link [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>]
<span class="h3"><a class="selflink" id="section-5.7" href="#section-5.7">5.7</a>. OSPFv2 Router Properties Registry</span>
<a href="#section-2.4.2">Section 2.4.2</a> defines the policy for allocation of bits from this
registry as "Standards Action". There are only 8 bits in this field,
and 5 are already assigned. The initial registry contents are given
below.
OSPFv2 Options Registry (<a href="#section-2.1">Section 2.1</a>)
Value Description Reference
----- ----------- ---------
0x01 B-bit [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>]
0x02 W-bit [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>]
0x04 V-bit [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>]
0x08 W-bit [<a href="./rfc1584" title=""Multicast Extensions to OSPF"">RFC1584</a>]
0x10 Nt-bit [<a href="./rfc3101" title=""The OSPF Not-So-Stubby Area (NSSA) Option"">RFC3101</a>]
<span class="grey">Kompella & Fenner Best Current Practice [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4940">RFC 4940</a> IANA Considerations for OSPF June 2007</span>
<span class="h3"><a class="selflink" id="section-5.8" href="#section-5.8">5.8</a>. OSPFv3 LSA Function Code Registry</span>
This registry is created by [<a href="#ref-OSPF-CAP" title=""Extensions to OSPF for Advertising Optional Router Capabilities"">OSPF-CAP</a>], which also defines the
registration policy. This section contains values that belong in
this registry that were defined by [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>].
As defined in [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>], the first 3 bits of the LSA Function
Code are the U, S1, and S2 bits. A given function code implies a
specific setting for the U, S1, and S2 bits as shown in the "LS Type"
column.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|U |S2|S1| LSA Function Code |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The U bit indicates how the LSA should be handled by a router which
does not recognize the LSA's function code. Its values are:
U-bit LSA Handling
----- ----------------------------------------------------
0 Treat the LSA as if it had link-local flooding scope
1 Store and flood the LSA, as if type understood
The S1 and S2 bits indicate the flooding scope of the LSA. The
values are:
S1 S2 Flooding Scope
-- -- --------------------------------------------------------------
0 0 Link-Local Scoping. Flooded only on link it is originated on
0 1 Area Scoping. Flooded to all routers in the originating area
1 0 AS Scoping. Flooded to all routers in the AS
1 1 Reserved
The initial registry contents are given below.
<span class="grey">Kompella & Fenner Best Current Practice [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4940">RFC 4940</a> IANA Considerations for OSPF June 2007</span>
OSPFv3 LSA Function Code (<a href="#section-2.5">Section 2.5</a>)
LSA Function Code LS Type Description Reference
----------------- ------- --------------------- ---------
1 0x2001 Router-LSA [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>]
2 0x2002 Network-LSA [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>]
3 0x2003 Inter-Area-Prefix-LSA [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>]
4 0x2004 Inter-Area-Router-LSA [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>]
5 0x4005 AS-External-LSA [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>]
6 0x2006 Group-membership-LSA [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>]
7 0x2007 Type-7-LSA [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>]
8 0x0008 Link-LSA [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>]
9 0x2009 Intra-Area-Prefix-LSA [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>]
<span class="h3"><a class="selflink" id="section-5.9" href="#section-5.9">5.9</a>. OSPFv3 Prefix Options Registry</span>
<a href="#section-2.5.1">Section 2.5.1</a> defines the policy for allocation of bits from this
registry as "Standards Action". There are only 8 bits in this field,
and 4 are already assigned. The initial registry contents are given
below.
OSPFv3 Prefix Options Registry (<a href="#section-2.5.1">Section 2.5.1</a>)
Value Description Reference
----- ----------- ---------
0x01 NU-bit [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>]
0x02 LA-bit [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>]
0x04 MC-bit [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>]
0x08 P-bit [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>]
<span class="h3"><a class="selflink" id="section-5.10" href="#section-5.10">5.10</a>. OSPFv3 Router LSA Link Type Registry</span>
<a href="#section-2.5.2">Section 2.5.2</a> defines the policy for allocations from this registry
for different ranges. The initial registry contents are given below.
OSPFv3 Router LSA Link Type (<a href="#section-2.5.2">Section 2.5.2</a>)
Value Description Reference
----- ------------------------------------------- ---------
1 Point-to-Point connection to another router [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>]
2 Transit Network [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>]
3 Reserved [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>]
4 Virtual Link [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>]
<span class="grey">Kompella & Fenner Best Current Practice [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4940">RFC 4940</a> IANA Considerations for OSPF June 2007</span>
<span class="h3"><a class="selflink" id="section-5.11" href="#section-5.11">5.11</a>. OSPFv2 Opaque LSA Type Registry</span>
This registry already exists at IANA, called "ospf-opaque-types".
<a href="#section-2.6">Section 2.6</a> defines the policy for allocation from this registry for
different ranges.
<span class="h3"><a class="selflink" id="section-5.12" href="#section-5.12">5.12</a>. OSPFv2 Grace LSA Top Level TLV Registry</span>
<a href="#section-2.6.1">Section 2.6.1</a> defines the policy for allocations from this registry
for different ranges. The initial registry contents are given below.
OSPFv2 Grace LSA Top Level TLV (<a href="#section-2.6.1">Section 2.6.1</a>)
Value Description Reference
----- ----------------------- ---------
1 Grace Period [<a href="./rfc3623" title=""Graceful OSPF Restart"">RFC3623</a>]
2 Graceful Restart reason [<a href="./rfc3623" title=""Graceful OSPF Restart"">RFC3623</a>]
3 IP Interface Address [<a href="./rfc3623" title=""Graceful OSPF Restart"">RFC3623</a>]
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Normative References</span>
[<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-RFC1584">RFC1584</a>] Moy, J., "Multicast Extensions to OSPF", <a href="./rfc1584">RFC 1584</a>, March
1994.
[<a id="ref-RFC1793">RFC1793</a>] Moy, J., "Extending OSPF to Support Demand Circuits", <a href="./rfc1793">RFC</a>
<a href="./rfc1793">1793</a>, April 1995.
[<a id="ref-RFC2328">RFC2328</a>] Moy, J., "OSPF Version 2", STD 54, <a href="./rfc2328">RFC 2328</a>, April 1998.
[<a id="ref-RFC2370">RFC2370</a>] Coltun, R., "The OSPF Opaque LSA Option", <a href="./rfc2370">RFC 2370</a>, July
1998.
[<a id="ref-RFC2434">RFC2434</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="./rfc2434">RFC 2434</a>,
October 1998.
[<a id="ref-RFC2740">RFC2740</a>] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", <a href="./rfc2740">RFC</a>
<a href="./rfc2740">2740</a>, December 1999.
[<a id="ref-RFC3101">RFC3101</a>] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
<a href="./rfc3101">RFC 3101</a>, January 2003.
<span class="grey">Kompella & Fenner Best Current Practice [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4940">RFC 4940</a> IANA Considerations for OSPF June 2007</span>
[<a id="ref-RFC3623">RFC3623</a>] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF
Restart", <a href="./rfc3623">RFC 3623</a>, November 2003.
[<a id="ref-RFC3630">RFC3630</a>] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", <a href="./rfc3630">RFC 3630</a>, September
2003.
[<a id="ref-RFC3692">RFC3692</a>] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", <a href="https://www.rfc-editor.org/bcp/bcp82">BCP 82</a>, <a href="./rfc3692">RFC 3692</a>, January 2004.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<a id="ref-ENTERPRISE-NUMBERS">ENTERPRISE-NUMBERS</a>]
"PRIVATE ENTERPRISE NUMBERS",
<a href="http://www.iana.org/assignments/enterprise-numbers">http://www.iana.org/assignments/enterprise-numbers</a>.
[<a id="ref-OSPF-CAP">OSPF-CAP</a>] Lindem, A., "Extensions to OSPF for Advertising Optional
Router Capabilities", Work in Progress, May 2007.
Authors' Addresses
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
EMail: kireeti@juniper.net
Bill Fenner
AT&T Labs--Research
1 River Oaks Place
San Jose, CA 95134
US
Phone: +1 (408) 493-8505
EMail: fenner@research.att.com
<span class="grey">Kompella & Fenner Best Current Practice [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4940">RFC 4940</a> IANA Considerations for OSPF June 2007</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kompella & Fenner Best Current Practice [Page 15]
</pre>
|
