You are here: irt.org | RFCs | RFC2329 [ previous next ]
NetworkWorkingGroup J. Moy
Requestfor 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
notspecifyan Internet standard ofany kind. Distributionof this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998).All Rights Reserved.
Abstract
This memo documentshow therequirements for advancing a routing
protocol toFull Standard, set out in [Ref2], have been metfor
OSPFv2.
Please sendcomments to ospf@gated.cornell.edu.
Table of Contents
1 Introduction ........................................... 2
2 Modifications since Draft Standardstatus .............. 3
2.1 Point-to-MultiPoint interface .......................... 4
2.2 Cryptographic Authentication ........................... 5
3 Updated implementation anddeployment experience ....... 5
4 Protocol Security ...................................... 7
References............................................. 8
Security Considerations ................................ 8
Author's Address ....................................... 8
Full Copyright Statement ............................... 9
Moy Informational[Page 1]
RFC 2329 OSPF Standardization Report April 1998 1. Introduction OSPFv2, herein abbreviated simply as OSPF, is an IPv4 routing protocol documentedin [Ref8]. OSPFis a link-staterouting protocol. It is designed to be runinternal to a single Autonomous System. Each OSPF router maintainsan identical database describing theAutonomous System's topology. From this database, a routing table is calculatedby constructinga shortest-pathtree. OSPF features include the following: oOSPF responds quickly to topology changes, expending a minimum of network bandwidth inthe process. oSupportfor CIDR addressing. oOSPF routing exchanges can be authenticated, providing routing security. oEqual-cost multipath. oAn arearoutingcapability is provided,enabling an Autonomous system to be split intoa two level hierarchy to further reduce the amount of routing protocol traffic. oOSPF allows import of external routing information intothe Autonomous System, including a tagging feature that canbe exploited to exchange extra informationat the AS boundary (see [Ref7]). An analysisof OSPFtogether with amore detailed description of OSPF features was originally provided in [Ref6], asa part of promoting OSPF to Draft Standard status. The analysis of OSPF remains unchanged. Two additional major features have been developed forOSPF since the protocolachieved Draft Standardstatus:the Point-to-MultiPointinterface and Cryptographic Authentication. These features are described in Sections 2.1 and 2.2 respectively of this memo. TheOSPF MIB is documented in [Ref4]. It iscurrently at Draft Standard status. Moy Informational[Page 2]
RFC 2329 OSPF Standardization Report April 1998 2. Modifications sinceDraft Standard status OSPF becamea DraftStandard with the release of RFC 1583 [Ref3]. Implementations of the new specification in[Ref8] are backward- compatible with RFC1583. The differences between the two documents aredescribed in the Appendix Gs of[Ref1] and [Ref8]. These differencesare listed briefly below. Two major features were also added, the Point-to-MultiPoint interface and Cryptographic Authentication, which are describedin separate sections. oConfiguration requirements for OSPF area address rangeshave been relaxed toallow greater flexibility in area assignment. See Section G.3of [Ref1] for details. oThe OSPF flooding algorithm wasmodified to a) improve database convergence in networkswith low speed links b)resolvea problemwhere unnecessary LSA retransmissions could occur as a result of differing clock granularities, c) remove race conditions between the floodingof MaxAge LSAs and the Database Exchange process, d) clarify the use ofthe MinLSArrival constant, and e) rate-limit theresponse to less recentLSAs received via flooding.See Sections G.4 and G.5 of [Ref1] and SectionG.1 of [Ref8] for details. oTo resolve the long-standing confusion regarding representation of point-to-point linksin OSPF, the specification now optionally allows advertisementof a stub link to a point-to- point link's subnet, ala RIP. See Section G.6 of [Ref1]. oSeveralproblems involving advertising the sameexternal route from multiple areas were found and fixed, as described in SectionG.7 of [Ref1] and Section G.2 of [Ref8]. Without the fixes, persistent routing loopscould form in certain such configurations.Note that one of the fixes was not backward- compatible, in that mixing routers implementingthe fixes with those implementing justRFC 1583 could cause loops not present in an RFC 1583-only configuration. Thiscaused an RFC1583Compatibility global configuration parameter to be added, as described inSectionC.1 of [Ref1]. Moy Informational[Page 3]
RFC 2329 OSPF Standardization Report April 1998 oIn order to deal with high delay links,retransmissionsof initialDatabase Description packets nolonger reset anOSPF adjacency. oIn order to detect linkMTU mismatches,which can causeproblems both inIP forwarding and in the OSPF routing protocol itself, MTU wasadded to OSPF'sDatabase Description packets. Neighboring routers refuse to bring up an OSPF adjacency unless they agree on their common link's MTU. oThe TOSroutingoption was deleted fromOSPF. 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. oOSPF's routing table lookup algorithm was changed to reflect currentpractice. The "best match" routing table entry is now always selectedto be the one providingthe most specific (longest) match. See Section G.4 of [Ref8] for details. 2.1. Point-to-MultiPoint interface The Point-to-MultiPointinterface was added as an alternative to OSPF's NBMA interface when running OSPFover non-broadcast subnets. Unlikethe NBMA interface, Point-to-MultiPointdoes not requirefull mesh connectivity over thenon-broadcast subnet. Point-to-MultiPoint is less efficient than NBMA, but iseasier 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 informationon the Point-to- MultiPoint interface, see Section G.2 of [Ref1]. There are at least six independent implementations of the Point-to-MultiPoint interface. Interoperabilityhas been demonstrated between atleast two pairsof implementations: between3com and Bay Networks, and between cisco and Cascade. Moy Informational[Page 4]
RFC 2329 OSPF Standardization Report April 1998 2.2. CryptographicAuthentication Non-trivial authentication was added toOSPF with the development of the Cryptographic Authenticationtype. This authentication type uses any keyed message digest algorithm, with explicit instructions included forthe useof MD5.For more information on OSPF authentication, seeSection4. There are at least three independent implementations ofthe OSPF Cryptographic authentication type. Interoperability hasbeen demonstrated between the implementations from cisco andCascade. 3. Updated implementation and deployment experience When OSPF was promoted to Draft Standard Status, a report was issued documentingcurrentimplementation and deployment experience (see [Ref6]). That report is nowquite dated. Inan attempt to get more current data, a questionnaire was sent to OSPF mailing listin January 1996. Twelve responses werereceived, from 11 router vendors and1 manufacturer of test equipment. Theseresponses represented 6 independentimplementations. A tabulation of the results are presented below. Table 1 indicates the implementation, interoperability and deployment of the major OSPF functions. Thenumber in each column represents the number of responses in the affirmative. Moy Informational[Page 5]
RFC 2329 OSPF Standardization Report April 1998 Imple-Inter- Feature mentedoperated Deployed _______________________________________________________ OSPF areas 1010 10 Stub areas 1010 9 Virtual links 109 8 Equal-cost multipath 107 8 NBMA support 98 7 CIDR addressing 85 6 OSPF MIB 85 5 Cryptographic auth. 32 1 Point-to-Multipointifc. 63 4 Table 1: Implementation of OSPF features Table 2 indicates the size of the OSPF routing domains thatvendors have tested. For each size parameter, the number ofresponders and therange of responses (minimum, mode, meanand maximum) are listed. Parameter ResponsesMin Mode Mean Max _________________________________________________________________ Max routers in domain 730 240 460 1600 Max routers in single area 720 240 380 1600 Max areas in domain 71 10 16 60 Max AS-external-LSAs 950 10K 10K 30K Table 2:OSPF domain sizes tested Table 3 indicates the size of the OSPF routing domains thatvendors have deployed in real networks. Foreach size parameter, the number of responders and the rangeof responses (minimum, mode, mean and maximum) are listed. Moy Informational[Page 6]
RFC 2329 OSPF Standardization Report April 1998 Parameter ResponsesMin Mode Mean Max _________________________________________________________________ Max routers in domain 820 350 510 1000 Max routers in single area 820 100 160 350 Max areas in domain 71 15 23 60 Max AS-external-LSAs 650 1K 2K 5K Table 3: OSPF domain sizes deployed In an attempt to ascertain the extent to which OSPFis currently deployed, vendors were alsoasked 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 AllOSPF protocol exchangesare authenticated. OSPFsupports multiple types of authentication; the type of authentication in use canbe configured on a per network segment basis. One of OSPF's authentication types, namely the Cryptographic authentication option, is believedto be secure against passive attacks and provide significantprotection against active attacks. Whenusing the Cryptographic authentication option, each router appends a "message digest" to its transmitted OSPF packets. Receivers then usethe shared secret key and received digest to verify that each received OSPF packetis authentic. Thequalityof the securityprovided by theCryptographic authentication option depends completely onthe strength ofthe message digest algorithm (MD5 is currently the onlymessagedigest algorithm specified), the strength of the key beingused, and the correct implementation of the security mechanism inall communicating OSPF implementations. It also requires that all parties maintain the secrecy of theshared secret key. None of theOSPF authentication types provide confidentiality. Nor do they protect against traffic analysis. Key management isalso not addressed by the OSPF specification. Moy Informational[Page 7]
RFC 2329 OSPF Standardization Report April 1998 Formore information, see Sections 8.1, 8.2, and Appendix Dof [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 InformationBase", RFC 1850, November 1995. [Ref5] Moy, J., "OSPF Protocol Analysis", RFC 1245, August1991. [Ref6] Moy, J., "Experience with the OSPF Protocol", RFC 1246, August 1991. [Ref7] Varadhan, K., HaresS., andY. 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 areaddressed 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 Moy Informational[Page 8]
RFC 2329 OSPF Standardization Report April 1998 Full Copyright Statement Copyright (C) The Internet Society (1998). AllRights Reserved. This document and translations of it may be copied and furnished to others, and derivative worksthat comment onor otherwise explainit or assist inits 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 thisparagraph are included on all such copies and derivative works. However, this document itself may not be modified in anyway, such as byremoving the copyright notice or references to the Internet Society or other Internet organizations, except as neededfor thepurposeof developing Internet standards in which case the proceduresfor copyrights definedin the InternetStandards process must be followed, or as required to translate it into languages other than English. The limited permissionsgrantedabove are perpetual andwill not be revoked by the Internet Society or its successors orassigns. This document and the information contained herein is provided on an "AS IS" basis andTHE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THATTHE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANYRIGHTS OR ANY IMPLIEDWARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Moy Informational[Page 9]