Movatterモバイル変換

Network Working Group                                             J. MoyRequest for Comments: 2329                   Ascend Communications, Inc.Category: Informational                                       April 1998OSPF Standardization ReportStatus 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 Contents1        Introduction ...........................................22        Modifications since Draft Standard status ..............32.1      Point-to-MultiPoint interface ..........................42.2      Cryptographic Authentication ...........................53        Updated implementation and deployment experience .......54        Protocol Security ......................................7             References .............................................8             Security Considerations ................................8             Author's Address .......................................8             Full Copyright Statement ...............................9Moy                          Informational                      [Page 1]

RFC 2329              OSPF Standardization Report             April 1998.  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 Sections2.1 and2.2 respectively of    this memo.    The OSPF MIB is documented in [Ref4]. It is currently at Draft    Standard status.Moy                          Informational                      [Page 2]

RFC 2329              OSPF Standardization Report             April 1998.  Modifications since Draft Standard status    OSPF became a Draft Standard with the release ofRFC 1583 [Ref3].    Implementations of the new specification in [Ref8] are backward-    compatible withRFC 1583. The differences between the two documents    are described in theAppendix 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 justRFC 1583 could cause loops not present        in anRFC 1583-only configuration. This caused an        RFC1583Compatibility global configuration parameter to be added,        as described in Section C.1 of [Ref1].Moy                          Informational                      [Page 3]

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.Moy                          Informational                      [Page 4]

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, seeSection 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..  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.Moy                          Informational                      [Page 5]

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.Moy                          Informational                      [Page 6]

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..  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.Moy                          Informational                      [Page 7]

RFC 2329              OSPF Standardization Report             April 1998    For more information, see Sections8.1,8.2, andAppendix 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 inSection 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.comMoy                          Informational                      [Page 8]

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.Moy                          Informational                      [Page 9]