Network Working Group J. Moy Internet Draft Sycamore Networks, Inc. Expiration Date: January 2000 July 1999 File name: draft-ietf-ospf-ospfv3-stdreport-00.txt OSPF for IPv6 Standardization Report Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo documents how OSPF for IPv6 meets the requirements for advancing a routing protocol to Proposed Standard, as set out in [Ref2]. Please send comments to ospf@discuss.microsoft.com. Moy [Page 1]
Internet Draft OSPF for IPv6 Standardization Report July 1999 Table of Contents 1 Introduction ........................................... 3 2 Protocol Features ...................................... 3 3 Protocol Suitability ................................... 4 4 Implementations ........................................ 4 5 MIB .................................................... 4 6 Protocol security ...................................... 4 7 Issues ................................................. 5 References ............................................. 6 Security Considerations ................................ 7 Authors' Addresses ..................................... 7 Moy [Page 2]
Internet Draft OSPF for IPv6 Standardization Report July 1999 1. Introduction The OSPFv2 routing protocol [Ref3] has been modified to support IP version 6, resulting in OSPF for IPv6 [Ref1], also called OSPFv3. The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, mostly in packet and LSA formats. These changes were necessary because of differences in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. 2. Protocol Features All of the standard OSPFv2 capabilities, such as quick convergence using a minimum of control traffic, equal-cost multipath and area routing, are supported in OSPF for IPv6. In addition, all of OSPFv2's optional capabilities, including on-demand circuit support, NSSA areas, and the multicast extensions to OSPF (MOSPF) are supported in OSPF for IPv6. The differences between OSPF for IPv6 and the OSPFv2 routing protocol are documented in Section 2 of [Ref1]. Those differences that can be seen by the people operating, configuring, or using an OSPF network are briefly mentioned below: o OSPF for IPv6 runs per-physical link, instead of OSPFv2's per-IP subnet behavior. This affects only those links that have been assigned multiple IP subnets. o OSPF for IPv6 supports the ability to run multiple OSPF protocol instances on a single link. For example, this may be required on a NAP segment shared between several providers -- providers may be running separate OSPF routing domains that want to remain separate even though they have one or more physical network segments (i.e., links) in common. In OSPFv2 this was supported in a haphazard fashion using the authentication fields in the OSPFv2 header. o Handling of unknown LSA types has been made more flexible so that, based on LS type, unknown LSA types are either treated as having link-local flooding scope, or are stored and flooded as if they were understood. Note: this feature fixes problems encountered in the incremental deployment of OSPFv2 extensions such as MOSPF [Ref10]. o OSPF for IPv6 supports a link-local flooding scope, like the one employed by OSPFv2 type 9 Opaque-LSAs [Ref14], in addition to OSPFv2's area- and AS-flooding scopes. Moy [Page 3]
Internet Draft OSPF for IPv6 Standardization Report July 1999 3. Protocol Suitability The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged in OSPF for IPv6. Most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4, even with the larger IPv6 addresses. As a result, the analysis and deployment experience of OSPFv2, documented in [Ref5], [Ref6] and [Ref13] should apply equally to OSPF for IPv6. In short, OSPF for IPv6 is an intra-domain routing protocol that converges quickly in the face of topological changes, using a minimal amount of resources (network bandwidth, router CPU and memory) in the process. The design of OSPF for IPv6 supports routing domains of large size and having complicated topologies. 4. Implementations There are two independent implementations of OSPF for IPv6. The first is an implementation by Keith Karlsson of IBM (karlsson@us.ibm.com). This implementation does not contain support for NBMA or Point-to-MultiPoint interfaces. It is currently being tested in a lab environment. The second is an implementation in the Zebra routing daemon (www.zebra.org), free software distributed under the GNU General Public License and implementing TCP/IP routing protocols. The implementation of OSPF for IPv6 is in the ospf6d subdirectory of the zebra distribution. It supports broadcast and point-to-point links, router-LSAs, network-LSAs, intra-area-prefix-LSAs and Link-LSAs. It does not support OSPF areas, nor does it support premature aging of LSAs or authentication. 5. MIB A MIB for OSPF for IPv6 has been developed [Ref7]. This MIB contains a group of General Variables and ten tables: areas, local- scope LSAs, area-scope LSAs, AS-scope LSAs, hosts, interfaces, virtual interfaces, neighbors, virtual neighbors and area aggregates. Differences between the OSPF for IPv6 MIB and the MIB for OSPFv2 [Ref4] are explained in Section 2 of [Ref7]. 6. Protocol Security In OSPF for IPv6, authentication has been removed from OSPF itself. The "AuType" and "Authentication" fields have been removed from the OSPF packet header, and all authentication related fields have been removed from the OSPF area and interface structures. Moy [Page 4]
Internet Draft OSPF for IPv6 Standardization Report July 1999 When running over IPv6, OSPF relies on the IP Authentication Header (see [Ref8]) and the IP Encapsulating Security Payload (see [Ref9]) to ensure integrity and authentication/confidentiality of routing exchanges. 7. Issues OSPF for IPv6 supports all the standard OSPFv2 functionality and mechanisms, which have been reported on and described in detail in [Ref5], [Ref6] and [Ref13]. However, a few characteristics of the OSPF for IPv6 should be noted. (1) OSPF Router IDs, Area IDs and LSA Link State IDs remain at the IPv4 size of 32-bits. This was done in order to keep the size of LSAs small. As a result, OSPF for IPv6 Router IDs cannot be assigned as one of the router's IPv6 addresses -- IPv4 addresses may be assigned to routers implementing OSPF for IPv6 solely for the purpose of obtaining OSPF Router IDs. (2) OSPF for IPv6 does not specify its own authentication mechanisms, instead relying on standard security mechanisms provided by IPv6's network layer (see Section 6). (3) An OSPF router wishing to forward IPv4 and IPv6 packets simultaneously would have to employ the so-called "Ships in the Night" strategy, running both OSPFv2 and OSPFv3 protocols at the same time. Moy [Page 5]
Internet Draft OSPF for IPv6 Standardization Report July 1999 References [Ref1] Coltun, R., D. Ferguson and J. Moy, "OSPF for IPv6", Internet Draft, <draft-ietf-ospf-ospfv6-06.txt>, June 1999. [Ref2] Hinden, B., "Internet Routing Protocol Standardization Criteria", RFC 1264, October 1991. [Ref3] Moy, J., "OSPF Version 2", RFC 2328, STD 54, April 1998. [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] Joyal, D., "Management Information Base for OSPFv3", Internet Draft, <draft-ietf-ospf-ospfv3-mib-00.txt>, July 1999. [Ref8] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, BBN Corp, @Home Network, November 1998. [Ref9] Kent S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, BBN Corp, @Home Network, November 1998. [Ref10] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, Inc., March 1994. [Ref11] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, RainbowBridge Communications, Stanford University, March 1994. [Ref12] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, Cascade, April 1995. [Ref13] Moy, J., "OSPF Standardization Report", RFC 2329, April 1998. [Ref14] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998. Moy [Page 6]
Internet Draft OSPF for IPv6 Standardization Report July 1999 Security Considerations Security considerations are addressed in Section 6 of this memo. Author's Address John Moy Sycamore Networks, Inc. 10 Elizabeth Drive Chelmsford, MA 01824 Phone: (978) 250-2975 Fax: (978) 256-3434 Email: jmoy@sycamorenet.com This document expires in January 2000. Moy [Page 7]
