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
|
<pre>Network Working Group J. Moy
Request for Comments: 2329 Ascend Communications, Inc.
Category: Informational April 1998
<span class="h1">OSPF Standardization Report</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 (1998). All Rights Reserved.
Abstract
This memo documents how the requirements for advancing a routing
protocol to Full Standard, set out in [<a href="#ref-Ref2" title=""Internet Routing Protocol Standardization Criteria"">Ref2</a>], have been met for
OSPFv2.
Please send comments to ospf@gated.cornell.edu.
Table of Contents
<a href="#section-1">1</a> Introduction ........................................... <a href="#page-2">2</a>
<a href="#section-2">2</a> Modifications since Draft Standard status .............. <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a> Point-to-MultiPoint interface .......................... <a href="#page-4">4</a>
<a href="#section-2.2">2.2</a> Cryptographic Authentication ........................... <a href="#page-5">5</a>
<a href="#section-3">3</a> Updated implementation and deployment experience ....... <a href="#page-5">5</a>
<a href="#section-4">4</a> Protocol Security ...................................... <a href="#page-7">7</a>
References ............................................. <a href="#page-8">8</a>
Security Considerations ................................ <a href="#page-8">8</a>
Author's Address ....................................... <a href="#page-8">8</a>
Full Copyright Statement ............................... <a href="#page-9">9</a>
<span class="grey">Moy Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc2329">RFC 2329</a> OSPF Standardization Report April 1998</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
OSPFv2, herein abbreviated simply as OSPF, is an IPv4 routing
protocol documented in [<a href="#ref-Ref8" title=""OSPF Version 2"">Ref8</a>]. OSPF is a link-state routing
protocol. It is designed to be run internal to a single Autonomous
System. Each OSPF router maintains an identical database describing
the Autonomous System's topology. From this database, a routing
table is calculated by constructing a shortest-path tree. OSPF
features include the following:
o OSPF responds quickly to topology changes, expending a minimum
of network bandwidth in the process.
o Support for CIDR addressing.
o OSPF routing exchanges can be authenticated, providing routing
security.
o Equal-cost multipath.
o An area routing capability is provided, enabling an Autonomous
system to be split into a two level hierarchy to further reduce
the amount of routing protocol traffic.
o OSPF allows import of external routing information into the
Autonomous System, including a tagging feature that can be
exploited to exchange extra information at the AS boundary (see
[<a href="#ref-Ref7" title=""BGP4/IDRP for IP-- -OSPF Interaction"">Ref7</a>]).
An analysis of OSPF together with a more detailed description of
OSPF features was originally provided in [<a href="#ref-Ref6" title=""Experience with the OSPF Protocol"">Ref6</a>], as a part of
promoting OSPF to Draft Standard status. The analysis of OSPF
remains unchanged. Two additional major features have been developed
for OSPF since the protocol achieved Draft Standard status: the
Point-to-MultiPoint interface and Cryptographic Authentication.
These features are described in Sections <a href="#section-2.1">2.1</a> and <a href="#section-2.2">2.2</a> respectively of
this memo.
The OSPF MIB is documented in [<a href="#ref-Ref4" title=""OSPF Version 2 Management Information Base"">Ref4</a>]. It is currently at Draft
Standard status.
<span class="grey">Moy Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc2329">RFC 2329</a> OSPF Standardization Report April 1998</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Modifications since Draft Standard status</span>
OSPF became a Draft Standard with the release of <a href="./rfc1583">RFC 1583</a> [<a href="#ref-Ref3" title=""OSPF Version 2"">Ref3</a>].
Implementations of the new specification in [<a href="#ref-Ref8" title=""OSPF Version 2"">Ref8</a>] are backward-
compatible with <a href="./rfc1583">RFC 1583</a>. The differences between the two documents
are described in the <a href="#appendix-G">Appendix G</a>s of [<a href="#ref-Ref1" title=""OSPF Version 2"">Ref1</a>] and [<a href="#ref-Ref8" title=""OSPF Version 2"">Ref8</a>]. These
differences are listed briefly below. Two major features were also
added, the Point-to-MultiPoint interface and Cryptographic
Authentication, which are described in separate sections.
o Configuration requirements for OSPF area address ranges have
been relaxed to allow greater flexibility in area assignment.
See Section G.3 of [<a href="#ref-Ref1" title=""OSPF Version 2"">Ref1</a>] for details.
o The OSPF flooding algorithm was modified to a) improve database
convergence in networks with low speed links b) resolve a
problem where unnecessary LSA retransmissions could occur as a
result of differing clock granularities, c) remove race
conditions between the flooding of MaxAge LSAs and the Database
Exchange process, d) clarify the use of the MinLSArrival
constant, and e) rate-limit the response to less recent LSAs
received via flooding. See Sections G.4 and G.5 of [<a href="#ref-Ref1" title=""OSPF Version 2"">Ref1</a>] and
Section G.1 of [<a href="#ref-Ref8" title=""OSPF Version 2"">Ref8</a>] for details.
o To resolve the long-standing confusion regarding representation
of point-to-point links in OSPF, the specification now
optionally allows advertisement of a stub link to a point-to-
point link's subnet, ala RIP. See Section G.6 of [<a href="#ref-Ref1" title=""OSPF Version 2"">Ref1</a>].
o Several problems involving advertising the same external route
from multiple areas were found and fixed, as described in
Section G.7 of [<a href="#ref-Ref1" title=""OSPF Version 2"">Ref1</a>] and Section G.2 of [<a href="#ref-Ref8" title=""OSPF Version 2"">Ref8</a>]. Without the
fixes, persistent routing loops could form in certain such
configurations. Note that one of the fixes was not backward-
compatible, in that mixing routers implementing the fixes with
those implementing just <a href="./rfc1583">RFC 1583</a> could cause loops not present
in an <a href="./rfc1583">RFC 1583</a>-only configuration. This caused an
RFC1583Compatibility global configuration parameter to be added,
as described in Section C.1 of [<a href="#ref-Ref1" title=""OSPF Version 2"">Ref1</a>].
<span class="grey">Moy Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc2329">RFC 2329</a> OSPF Standardization Report April 1998</span>
o In order to deal with high delay links, retransmissions of
initial Database Description packets no longer reset an OSPF
adjacency.
o In order to detect link MTU mismatches, which can cause problems
both in IP forwarding and in the OSPF routing protocol itself,
MTU was added to OSPF's Database Description packets.
Neighboring routers refuse to bring up an OSPF adjacency unless
they agree on their common link's MTU.
o The TOS routing option was deleted from OSPF. However, for
backward compatibility the formats of OSPF's various LSAs remain
unchanged, maintaining the ability to specify TOS metrics in
router-LSAs, summary-LSAs, ASBR-summary-LSAs, and AS-external-
LSAs.
o OSPF's routing table lookup algorithm was changed to reflect
current practice. The "best match" routing table entry is now
always selected to be the one providing the most specific
(longest) match. See Section G.4 of [<a href="#ref-Ref8" title=""OSPF Version 2"">Ref8</a>] for details.
2.1. Point-to-MultiPoint interface
The Point-to-MultiPoint interface was added as an alternative to
OSPF's NBMA interface when running OSPF over non-broadcast
subnets. Unlike the NBMA interface, Point-to-MultiPoint does not
require full mesh connectivity over the non-broadcast subnet.
Point-to-MultiPoint is less efficient than NBMA, but is easier
to configure (in fact, it can be self-configuring) and is more
robust than NBMA, tolerating all failures within the non-
broadcast subnet. For more information on the Point-to-
MultiPoint interface, see Section G.2 of [<a href="#ref-Ref1" title=""OSPF Version 2"">Ref1</a>].
There are at least six independent implementations of the
Point-to-MultiPoint interface. Interoperability has been
demonstrated between at least two pairs of implementations:
between 3com and Bay Networks, and between cisco and Cascade.
<span class="grey">Moy Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc2329">RFC 2329</a> OSPF Standardization Report April 1998</span>
2.2. Cryptographic Authentication
Non-trivial authentication was added to OSPF with the
development of the Cryptographic Authentication type. This
authentication type uses any keyed message digest algorithm,
with explicit instructions included for the use of MD5. For more
information on OSPF authentication, see <a href="#section-4">Section 4</a>.
There are at least three independent implementations of the OSPF
Cryptographic authentication type. Interoperability has been
demonstrated between the implementations from cisco and Cascade.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Updated implementation and deployment experience</span>
When OSPF was promoted to Draft Standard Status, a report was issued
documenting current implementation and deployment experience (see
[<a href="#ref-Ref6" title=""Experience with the OSPF Protocol"">Ref6</a>]). That report is now quite dated. In an attempt to get more
current data, a questionnaire was sent to OSPF mailing list in
January 1996. Twelve responses were received, from 11 router vendors
and 1 manufacturer of test equipment. These responses represented 6
independent implementations. A tabulation of the results are
presented below.
Table 1 indicates the implementation, interoperability and
deployment of the major OSPF functions. The number in each column
represents the number of responses in the affirmative.
<span class="grey">Moy Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc2329">RFC 2329</a> OSPF Standardization Report April 1998</span>
Imple- Inter-
Feature mented operated Deployed
_______________________________________________________
OSPF areas 10 10 10
Stub areas 10 10 9
Virtual links 10 9 8
Equal-cost multipath 10 7 8
NBMA support 9 8 7
CIDR addressing 8 5 6
OSPF MIB 8 5 5
Cryptographic auth. 3 2 1
Point-to-Multipoint ifc. 6 3 4
Table 1: Implementation of OSPF features
Table 2 indicates the size of the OSPF routing domains that vendors
have tested. For each size parameter, the number of responders and
the range of responses (minimum, mode, mean and maximum) are listed.
Parameter Responses Min Mode Mean Max
_________________________________________________________________
Max routers in domain 7 30 240 460 1600
Max routers in single area 7 20 240 380 1600
Max areas in domain 7 1 10 16 60
Max AS-external-LSAs 9 50 10K 10K 30K
Table 2: OSPF domain sizes tested
Table 3 indicates the size of the OSPF routing domains that vendors
have deployed in real networks. For each size parameter, the number
of responders and the range of responses (minimum, mode, mean and
maximum) are listed.
<span class="grey">Moy Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc2329">RFC 2329</a> OSPF Standardization Report April 1998</span>
Parameter Responses Min Mode Mean Max
_________________________________________________________________
Max routers in domain 8 20 350 510 1000
Max routers in single area 8 20 100 160 350
Max areas in domain 7 1 15 23 60
Max AS-external-LSAs 6 50 1K 2K 5K
Table 3: OSPF domain sizes deployed
In an attempt to ascertain the extent to which OSPF is currently
deployed, vendors were also asked in January 1998 to provide
deployment estimates. Four vendors of OSPF routers responded, with a
total estimate of 182,000 OSPF routers in service, organized into
4300 separate OSPF routing domains.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Protocol Security</span>
All 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 OSPF authentication types provide confidentiality. Nor
do they protect against traffic analysis. Key management is also not
addressed by the OSPF specification.
<span class="grey">Moy Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc2329">RFC 2329</a> OSPF Standardization Report April 1998</span>
For more information, 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-Ref1" title=""OSPF Version 2"">Ref1</a>].
References
[<a id="ref-Ref1">Ref1</a>] Moy, J., "OSPF Version 2", <a href="./rfc2178">RFC 2178</a>, July 1997.
[<a id="ref-Ref2">Ref2</a>] Hinden, B., "Internet Routing Protocol Standardization
Criteria", <a href="./rfc1264">RFC 1264</a>, October 1991.
[<a id="ref-Ref3">Ref3</a>] Moy, J., "OSPF Version 2", <a href="./rfc1583">RFC 1583</a>, March 1994.
[<a id="ref-Ref4">Ref4</a>] Baker, F., and R. Coltun, "OSPF Version 2 Management
Information Base", <a href="./rfc1850">RFC 1850</a>, November 1995.
[<a id="ref-Ref5">Ref5</a>] Moy, J., "OSPF Protocol Analysis", <a href="./rfc1245">RFC 1245</a>, August 1991.
[<a id="ref-Ref6">Ref6</a>] Moy, J., "Experience with the OSPF Protocol", <a href="./rfc1246">RFC 1246</a>,
August 1991.
[<a id="ref-Ref7">Ref7</a>] Varadhan, K., Hares S., and Y. Rekhter, "BGP4/IDRP for IP--
-OSPF Interaction", <a href="./rfc1745">RFC 1745</a>, December 1994.
[<a id="ref-Ref8">Ref8</a>] Moy, J., "OSPF Version 2", STD 54, <a href="./rfc2328">RFC 2328</a>, April 1998.
Security Considerations
Security considerations are addressed in <a href="#section-4">Section 4</a> of this memo.
Author's Address
John Moy
Ascend Communications, Inc.
1 Robbins Road
Westford, MA 01886
Phone: 978-952-1367
Fax: 978-392-2075
EMail: jmoy@casc.com
<span class="grey">Moy Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc2329">RFC 2329</a> OSPF Standardization Report April 1998</span>
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright
notice and this paragraph are included on all such copies and
derivative works. However, this document itself may not be
modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Moy Informational [Page 9]
</pre>
|
