RFC 2329

OSPF Standardization Report

📅 published April 1998, from ietf

RFC 2329: OSPF Standardization Report 🎀

okay bestie, so this is an RFC from the Network Working Group, written by J. Moy at Ascend Communications, Inc. 💖 It's Informational (so it's giving "here's a report," not a new standard), dated April 1998. It doesn't obsolete or update anything. The whole thing is about one question: how did OSPF meet the bar to become a Full Standard? 🦋

Status of this Memo 🫶

this memo just provides info for the Internet community. it's not a standard of any kind, and you can distribute it as much as you want ✨

Copyright (C) The Internet Society (1998). All Rights Reserved.

Abstract 🌸

this memo documents how the requirements for moving a routing protocol up to Full Standard, which are set out in [Ref2], have been met for OSPFv2. it's literally the receipts 🧾

comments go 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

1. Introduction ✨

OSPFv2 (we'll just call it OSPF, bestie) is an IPv4 routing protocol, and it's documented in [Ref8] 🌈 It's a link-state routing protocol, and it's built to run inside one Autonomous System. every OSPF router keeps an identical database that describes the AS's topology. from that database, each router works out a routing table by building a shortest-path tree. the main features are:

  • OSPF reacts fast to topology changes and uses barely any network bandwidth doing it 🔥
  • CIDR addressing is supported 💜
  • OSPF routing exchanges can be authenticated, which gives you routing security 🔐
  • Equal-cost multipath is a thing 🍓
  • an area routing capability lets an Autonomous System get split into a two-level hierarchy, which cuts down the routing protocol traffic even more 👑
  • OSPF can import external routing info into the AS, and there's a tagging feature you can use to pass extra info across the AS boundary (see [Ref7]) 🧚

the analysis of OSPF, along with a more detailed look at its features, was first written up in [Ref6] when OSPF was getting promoted to Draft Standard. that analysis hasn't changed at all. since OSPF hit Draft Standard, two big new features have shown up: the Point-to-MultiPoint interface and Cryptographic Authentication. you'll find those in Sections 2.1 and 2.2 of this memo 🙈

the OSPF MIB is documented in [Ref4], and it's currently at Draft Standard status 💅

2. Modifications since Draft Standard status 🦋

OSPF became a Draft Standard when RFC 1583 [Ref3] came out. the new spec in [Ref8] is backward-compatible with RFC 1583. the differences between the two are described in the Appendix Gs of [Ref1] and [Ref8]. the main changes are listed below. two major features also got added, the Point-to-MultiPoint interface and Cryptographic Authentication, and each one has its own section 🌸

  • the configuration requirements for OSPF area address ranges got relaxed, so you get more flexibility when assigning areas. see Section G.3 of [Ref1] for the details 🎀
  • the OSPF flooding algorithm got modified to: a) improve database convergence in networks with low speed links, b) fix a problem where unnecessary LSA retransmissions could happen because of differing clock granularities, c) remove race conditions between the flooding of MaxAge LSAs and the Database Exchange process, d) clarify how the MinLSArrival constant gets used, 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 the details ⭐
  • to clear up the long-running confusion about how point-to-point links get represented in OSPF, the spec now optionally allows advertising a stub link to a point-to-point link's subnet, ala RIP. see Section G.6 of [Ref1] 🧁
  • several problems came up when the same external route was advertised from multiple areas. they got 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 configurations 😭 one of the fixes isn't backward-compatible, though. mixing routers that have the fixes with routers that only have RFC 1583 can cause loops that don't exist in an RFC 1583-only setup. that's why an RFC1583Compatibility global configuration parameter got added, as described in Section C.1 of [Ref1] 💀
  • to handle high delay links, retransmissions of initial Database Description packets no longer reset an OSPF adjacency 🫶
  • to detect link MTU mismatches (which can cause problems both in IP forwarding and in the OSPF routing protocol itself), MTU got 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 🔥
  • the TOS routing option got deleted from OSPF. for backward compatibility, though, the formats of OSPF's various LSAs stay the same, so you can still specify TOS metrics in router-LSAs, summary-LSAs, ASBR-summary-LSAs, and AS-external-LSAs 🌈
  • OSPF's routing table lookup algorithm changed to match current practice. the "best match" routing table entry is now always the one with the most specific (longest) match. see Section G.4 of [Ref8] for the details 👑

2.1. Point-to-MultiPoint interface 🧚

the Point-to-MultiPoint interface got added as an alternative to OSPF's NBMA interface for running OSPF over non-broadcast subnets. unlike NBMA, Point-to-MultiPoint doesn't need full mesh connectivity over the non-broadcast subnet. it's less efficient than NBMA, but it's easier to configure (it can even be self-configuring) and more robust than NBMA, since it tolerates all failures within the non-broadcast subnet 🦋 for more on this, see Section G.2 of [Ref1].

there are at least six independent implementations of the Point-to-MultiPoint interface 💖 interop has been shown between at least two pairs of them: 3com and Bay Networks, and cisco and Cascade 🎀

2.2. Cryptographic Authentication 🔐

non-trivial authentication got added to OSPF with the Cryptographic Authentication type. this type uses any keyed message digest algorithm, with explicit instructions for using MD5. for more on OSPF authentication, see Section 4 🌸

there are at least three independent implementations of the OSPF Cryptographic authentication type 💜 interop has been shown between the cisco and Cascade implementations 🫶

part 2 is coming with the good stuff: Section 3 (the deployment data, tables and all 📊), Section 4 (protocol security), and the references, security considerations, and author's address 👀

References ✨

okay this is the reading list, bestie 📚 Every source the spec leans on is here, and I've kept every detail so nothing gets lost.

[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. (this one is the big OSPF v2 spec, the main character of the whole family 💜)

Security Considerations 🔐

ngl this section is short and sweet 💅 Security considerations are addressed in Section 4 of this memo, so go check out the protocol security part I covered earlier. That's where all the serious stuff lives 🫶

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

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.

that's the whole RFC, bestie 🦋✨

📦 where this page comes from