OSPFv2 Report: OSPF Standardization Report
A report showing how OSPF version 2 routing protocol met all requirements to become a Full Internet Standard.
Moy, J., "OSPF Standardization Report", RFC 2329, DOI 10.17487/RFC2329, April 1998, <https://www.rfc-editor.org/info/rfc2329>.
@misc{rfc2329,
series = {Request for Comments},
number = 2329,
howpublished = {RFC 2329},
publisher = {RFC Editor},
doi = {10.17487/RFC2329},
url = {https://www.rfc-editor.org/info/rfc2329},
author = {J. Moy},
title = {{OSPF Standardization Report}},
pagetotal = 9,
year = 1998,
month = apr,
} RFC text
Contents
Network Working Group J. Moy Request for Comments: 2329 Ascend Communications, Inc. Category: Informational April 1998 OSPF Standardization Report 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 [Ref2], have been met for OSPFv2. Please send comments to ospf@gated.cornell.edu. Table of Contents 1 Introduction ........................................... 2 2 Modifications since Draft Standard status .............. 3 2.1 Point-to-MultiPoint interface .......................... 4 2.2 Cryptographic Authentication ........................... 5 3 Updated implementation and deployment experience ....... 5 4 Protocol Security ...................................... 7 References ............................................. 8 Security Considerations ................................ 8 Author's Address ....................................... 8 Full Copyright Statement ............................... 9 RFC 2329 OSPF Standardization Report April 1998 1. Introduction OSPFv2, herein abbreviated simply as OSPF, is an IPv4 routing protocol documented in [Ref8]. 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 [Ref7]). An analysis of OSPF together with a more detailed description of OSPF features was originally provided in [Ref6], 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 2.1 and 2.2 respectively of this memo. The OSPF MIB is documented in [Ref4]. It is currently at Draft Standard status. RFC 2329 OSPF Standardization Report April 1998 2. Modifications since Draft Standard status OSPF became a Draft Standard with the release of RFC 1583 [Ref3]. Implementations of the new specification in [Ref8] are backward- compatible with RFC 1583. The differences between the two documents are described in the Appendix Gs of [Ref1] and [Ref8]. 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 [Ref1] 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 [Ref1] and Section G.1 of [Ref8] 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 [Ref1]. o Several problems involving advertising the same external route from multiple areas were found and fixed, as described in Section G.7 of [Ref1] and Section G.2 of [Ref8]. 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 RFC 1583 could cause loops not present in an RFC 1583-only configuration. This caused an RFC1583Compatibility global configuration parameter to be added, as described in Section C.1 of [Ref1]. RFC 2329 OSPF Standardization Report April 1998 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 [Ref8] 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 [Ref1]. 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. RFC 2329 OSPF Standardization Report April 1998 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 Section 4. There are at least three independent implementations of the OSPF Cryptographic authentication type. Interoperability has been demonstrated between the implementations from cisco and Cascade. 3. Updated implementation and deployment experience When OSPF was promoted to Draft Standard Status, a report was issued documenting current implementation and deployment experience (see [Ref6]). 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. RFC 2329 OSPF Standardization Report April 1998 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. RFC 2329 OSPF Standardization Report April 1998 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. 4. Protocol Security 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. RFC 2329 OSPF Standardization Report April 1998 For more information, see Sections 8.1, 8.2, and Appendix D of [Ref1]. References [Ref1] Moy, J., "OSPF Version 2", RFC 2178, July 1997. [Ref2] Hinden, B., "Internet Routing Protocol Standardization Criteria", RFC 1264, October 1991. [Ref3] Moy, J., "OSPF Version 2", RFC 1583, March 1994. [Ref4] Baker, F., and R. Coltun, "OSPF Version 2 Management Information Base", RFC 1850, November 1995. [Ref5] Moy, J., "OSPF Protocol Analysis", RFC 1245, August 1991. [Ref6] Moy, J., "Experience with the OSPF Protocol", RFC 1246, August 1991. [Ref7] Varadhan, K., Hares S., and Y. Rekhter, "BGP4/IDRP for IP-- -OSPF Interaction", RFC 1745, December 1994. [Ref8] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. Security Considerations Security considerations are addressed in Section 4 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 RFC 2329 OSPF Standardization Report April 1998 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.
AI ELI5
On this page
§1Introduction
OSPF (Open Shortest Path First) is an interior gateway protocol used by routers within a single organization to share information about the network's topology (its physical layout and connections). OSPF is a link-state protocol, meaning each router maintains a complete map of the entire network, computes the shortest path to every destination, and quickly adapts when the network changes.
This RFC documents how OSPF version 2 (OSPFv2) satisfied the formal criteria for becoming a Full Internet Standard. It demonstrates that OSPF has been implemented by multiple independent vendors, successfully interoperates between those implementations, is widely deployed in production networks, and has proper security mechanisms. These criteria ensure that a protocol is mature and trustworthy before it earns Full Standard status.
Routers use OSPF to share maps of the network with each other so they know where to send data. This RFC proves OSPF works well enough to be an official Internet standard.
§2OSPF Features and Design
OSPF provides several important capabilities for modern routing. It responds quickly to topology changes, using minimal network bandwidth compared to older protocols like RIP. It supports CIDR addressing, the efficient IP address allocation scheme. OSPF exchanges can be authenticated to ensure routers only trust routing information from authorized peers. The protocol supports equal-cost multipath, allowing traffic to be distributed across multiple equivalent routes.
OSPF can divide an Autonomous System into areas, creating a two-level routing hierarchy that reduces the amount of routing traffic. It also allows import of external routing information (learned from other routing protocols), with a tagging mechanism to exchange additional information at AS boundaries. These features make OSPF both powerful and flexible for large networks.
OSPF lets routers quickly notice when the network changes, use efficient addresses, check that messages are real, and organize large networks into smaller sections.
§3Enhancements Since Draft Standard
OSPF became a Draft Standard with RFC 1583 in March 1994. Since then, the protocol was refined and two major features were added. The protocol's flooding algorithm was improved to handle low-speed links better, resolve database synchronization issues, prevent unnecessary retransmissions, and rate-limit responses to outdated link state advertisements.
Two significant new capabilities were added after Draft Standard status: the Point-to-MultiPoint interface allows OSPF to run over non-broadcast networks (like satellite links) without requiring every router to connect to every other router directly, making OSPF more flexible. Cryptographic Authentication allows routers to verify each OSPF message using keyed message digest algorithms (such as MD5), protecting against spoofed routing updates. Interoperability between multiple vendors was demonstrated for both features, with at least six Point-to-MultiPoint implementations and three Cryptographic Authentication implementations.
Since 1994, OSPF was improved to handle difficult networks better and two new features were added: a way to work on non-direct links and a way to sign messages so routers know they are real.
§4Implementation and Deployment Data
The RFC presents evidence of widespread OSPF implementation and deployment. A questionnaire sent to the OSPF mailing list in January 1996 received twelve responses from eleven router vendors and one test equipment manufacturer, representing six independent implementations. The response data shows: OSPF areas and stub areas were implemented and interoperated in 10 out of 10 responding implementations; virtual links in 10 implementations (with 9 able to interoperate); equal-cost multipath in 10 implementations (7 interoperating); and NBMA (non-broadcast multi-access) support in 9 implementations.
Testing data demonstrates that vendors had tested OSPF with up to 1600 routers in a domain and 30,000 external routes. Real-world deployment data from January 1998 showed OSPF in networks as large as 1000 routers in a domain. Four vendors estimated a combined 182,000 OSPF routers in service worldwide, organized into 4,300 separate OSPF routing domains. This level of implementation diversity and deployment scale directly satisfies the standardization criteria.
Survey answers showed that many different companies had built OSPF, they could all talk to each other, and thousands of real networks were using OSPF successfully.
| Feature | Implemented | Interoperated | Deployed |
|---|---|---|---|
| OSPF areas | 10 | 10 | 10 |
| Stub areas | 10 | 10 | 9 |
| Virtual links | 10 | 9 | 8 |
| Equal-cost multipath | 10 | 7 | 8 |
| NBMA support THIS RFC | 9 | 8 | 7 |
| CIDR addressing | 8 | 5 | 6 |
§5Protocol Security and Authentication
OSPF supports multiple authentication types that can be configured per network segment. All OSPF protocol exchanges are authenticated, meaning every router verifies the source of routing information it receives. The simplest authentication type is a plaintext password, but this provides only basic protection.
The Cryptographic Authentication type is considered secure against passive attacks (eavesdropping) and provides significant protection against active attacks (message injection or modification). When enabled, each router appends a message digest (computed using MD5 and a shared secret key) to its transmitted OSPF packets. Receiving routers verify the digest to confirm that the packet is authentic and has not been tampered with. However, cryptographic authentication does not provide confidentiality (the messages are still readable) and does not protect against traffic analysis. Key management is also outside the scope of the OSPF protocol itself.
OSPF can use secret signatures on messages so routers know they are talking to real routers, not imposters.
§6Path to Full Standard Status
The standardization process for routing protocols is defined in RFC 1264. To advance from Draft Standard to Full Standard requires demonstrating that the protocol is mature, widely implemented, thoroughly tested, and operationally viable. This RFC provides all required evidence: multiple independent implementations from different vendors, demonstrated interoperability between those implementations, real-world deployment at scale, and documented security mechanisms.
The report fulfills the formal documentation requirement by analyzing OSPF's achievements against the standardization criteria. The publication of this report in April 1998 accompanied the publication of RFC 2328, which is the authoritative specification for OSPF version 2 at Full Standard level. The clear evidence of maturity and widespread adoption justified OSPF's advancement to the highest standardization level.
This RFC shows that OSPF has been tested enough and is used widely enough to become an official Full Standard for routing.