One document matched: 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]