[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 01 02 03 04 05 06 07 08 rfc2740                               
Network Working Group                                          R. Coltun
Internet Draft                                              FORE Systems
Expiration Date: August 1996                                 D. Ferguson
File name: draft-ietf-ospf-ospfv6-01.txt                Ipsilon Networks
Network Working Group                                             J. Moy
Internet Draft                              Cascade Communications Corp.
                                                           February 1996


                             OSPF for IPv6



Status of this Memo

    This document is an Internet-Draft.  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".

    To learn the current status of any Internet-Draft, please check the
    "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
    ftp.isi.edu (US West Coast).

Abstract

    This document describes the modifications to OSPF to support version
    6 of the Internet Protocol (IPv6).  The fundamental mechanisms of
    OSPF (flooding, DR election, area support, SPF calculations, etc.)
    remain unchanged. However, some changes have been necessary, either
    due to changes in protocol semantics between IPv4 and IPv6, or
    simply to handle the increased address size of IPv6.

    Changes between OSPF for IPv4 and this document include the
    following. Addressing semantics have been removed from OSPF packets
    and the basic LSAs. New LSAs have been created to carry IPv6
    addresses and prefixes. OSPF now runs a a per-link basis, instead of
    on a per-IP-subnet basis. Flooding scope for LSAs has been
    generalized. Authentication has been removed from the OSPF protocol
    itself, instead relying on IPv6's Authentication Header and
    Encapsulating Security Payload.



Coltun et al                                                    [Page 1]


Internet Draft               OSPF for IPv6                 February 1996


    Most packets in OSPF for IPv6 are almost as compact as those in OSPF
    for IPv4l, even with the larger IPv6 addresses. Most field- and
    packet-size limitations present in OSPF for IPv4 have been relaxed.
    In addition, option handling has been made more flexible.

    All of OSPF for IPv4's optional capabilities, including on-demand
    circuit support, NSSA areas, and the multicast extensions to OSPF
    (MOSPF) are also supported in OSPF for IPv6.

    Please send comments to ospf@gated.cornell.edu.









































Coltun et al                                                    [Page 2]


Internet Draft               OSPF for IPv6                 February 1996


Table of Contents

    1        Introduction ........................................... 5
    1.1      Terminology ............................................ 5
    2        Differences from OSPF for IPv4 ......................... 5
    2.1      Protocol processing per-link, not per-subnet ........... 5
    2.2      Removal of addressing semantics ........................ 6
    2.3      Addition of Flooding scope ............................. 6
    2.4      Explicit support for multiple instances per link ....... 7
    2.5      Use of link-local addresses ............................ 7
    2.6      Authentication changes ................................. 7
    2.7      Packet format changes .................................. 8
    2.8      LSA format changes ..................................... 8
    2.9      Handling unknown LSA types ............................ 10
    2.10     Removal of TOS ........................................ 10
    3        Implementation details ................................ 11
             References ............................................ 12
    A        OSPF data formats ..................................... 14
    A.1      Encapsulation of OSPF packets ......................... 14
    A.2      The Options field ..................................... 16
    A.3      OSPF Packet Formats ................................... 18
    A.3.1    The OSPF packet header ................................ 19
    A.3.2    The Hello packet ...................................... 21
    A.3.3    The Database Description packet ....................... 23
    A.3.4    The Link State Request packet ......................... 25
    A.3.5    The Link State Update packet .......................... 26
    A.3.6    The Link State Acknowledgment packet .................. 27
    A.4      LSA formats ........................................... 28
    A.4.1    IPv6 Prefix Representation ............................ 30
    A.4.1.1  Prefix Options ........................................ 31
    A.4.2    The LSA header ........................................ 32
    A.4.2.1  LS type ............................................... 34
    A.4.3    Router-LSAs ........................................... 36
    A.4.4    Network-LSAs .......................................... 39
    A.4.5    Inter-Area-Prefix-LSAs ................................ 40
    A.4.6    Inter-Area-Router-LSAs ................................ 41
    A.4.7    AS-external-LSAs ...................................... 42
    A.4.8    Link-LSAs ............................................. 44
    A.4.9    Intra-Area-Prefix-LSAs ................................ 46
    B        Architectural Constants ............................... 48
    C        Configurable Constants ................................ 48
    C.1      Global parameters ..................................... 48
    C.2      Area parameters ....................................... 48
    C.3      Router interface parameters ........................... 49
    C.4      Virtual link parameters ............................... 51
    C.5      NBMA network parameters ............................... 52
    C.6      Point-to-MultiPoint network parameters ................ 53
    C.7      Host route parameters ................................. 53



Coltun et al                                                    [Page 3]


Internet Draft               OSPF for IPv6                 February 1996


             Security Considerations ............................... 54
             Authors' Addresses .................................... 54

















































Coltun et al                                                    [Page 4]


Internet Draft               OSPF for IPv6                 February 1996


1.  Introduction

    This document describes the modifications to OSPF to support version
    6 of the Internet Protocol (IPv6).  The fundamental mechanisms of
    OSPF (flooding, DR election, area support, SPF calculations, etc.)
    remain unchanged. However, some changes have been necessary, either
    due to changes in protocol semantics between IPv4 and IPv6, or
    simply to handle the increased address size of IPv6.

    This document is organized as follows. Section 2 describes the
    differences betweed OSPF for IPv4 and OSPF for IPv6 in detail.
    Section 3 provides implementation details for the changes. Appendix
    A gives the OSPF for IPv6 packet and LSA formats. Appendix B lists
    the OSPF architectural constants. Appendix C describes configuration
    parameters.

    1.1.  Terminology

        This document attempts to use terms from both the OSPF for IPv4
        specification ([Ref1]) and the IPv6 protocol specifications
        ([Ref14]). This has produced a mixed result. Most of the terms
        used both by OSPF and IPv6 have roughly the same meaning (e.g.,
        interfaces). However, there are a few conflicts. IPv6 uses
        "link" similarly to IPv4 OSPF's "subnet" or "network". In this
        case, we have chosen to use IPv6's "link" terminology. "Link"
        replaces OSPF's "subnet" and "network" in most places in this
        document, although OSPF's Network-LSA remains unchanged (and
        possibly unfortunately, a new Link-LSA has also been created).

        The names of some of the OSPF LSAs have also changed. See
        Section 2.8 for details.

2.  Differences from OSPF for IPv4

    Most of the algorithms from OSPF for IPv4 [Ref1] have preserved in
    OSPF for IPv6. However, some changes have been necessary, either due
    to changes in protocol semantics between IPv4 and IPv6, or simply to
    handle the increased address size of IPv6.

    The following subsections describe the differences between this
    document and [Ref1].

    2.1.  Protocol processing per-link, not per-subnet

        IPv6 uses the term "link" to indicate "a communication facility
        or medium over which nodes can communicate at the link layer"
        ([Ref14]).  "Interfaces" connect to links. Multiple IP subnets
        can be assigned to a single link, and two nodes can talk



Coltun et al                                                    [Page 5]


Internet Draft               OSPF for IPv6                 February 1996


        directly over a single link, even if they do not share a common
        IP subnet (IPv6 prefix).

        For this reason, OSPF for IPv6 runs per-link instead of the IPv4
        behavior of per-IP-subnet. The terms "network" and "subnet" used
        in the IPv4 OSPF specification ([Ref1]) should generally be
        relaced by link. Likewise, an OSPF interface now connects to a
        link instead of and IP subnet, etc.

        This change affects the receiving of OSPF protocol packets, and
        the contents of Hello Packets and Network-LSAs.

    2.2.  Removal of addressing semantics

        In OSPF for IPv6, addressing semantics have been removed from
        the OSPF protocol packets and the main LSA types, leaving a
        network-protocol-independent core. In particular:

        o   IPv6 Addresses are not present in OSPF packets, except for
            in LSA payloads carried by the Link State Update Packets.
            See Section 2.7 for details.

        o   Router-LSAs and Network-LSAs no longer contain network
            addresses, but simply express topology information. See
            Section 2.8 for details.

        o   OSPF Router IDs, Area IDs and LSA Link State IDs remain at
            the IPv4 size of 32-bits. They can no longer be assigned as
            (IPv6) addresses.

        o   Neighboring routers are now always identified by Router ID,
            where previously they had been identified by IP address on
            broadcast and NBMA "networks".

    2.3.  Addition of Flooding scope

        Flooding scope for LSAs has been generalized and is now
        explicitly coded in the LSA's LS type field. There are now three
        separate flooding scopes for LSAs:

        o   Link-local scope. LSA is flooded only on the local link, and
            no further. Used for the new Link-LSA (see Section A.4.8).

        o   Area scope. LSA is flooded throughout a single OSPF area
            only. Used for Router-LSAs, Network-LSAs, Inter-Area-
            Prefix-LSAs, Inter-Area-Router-LSAs and Intra-Area-Prefix-
            LSAs.




Coltun et al                                                    [Page 6]


Internet Draft               OSPF for IPv6                 February 1996


        o   AS scope. LSA is flooded throughout the routing domain. Used
            for AS-external-LSAs.

    2.4.  Explicit support for multiple instances per link

        OSPF now 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 a 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 OSPF for IPv4 this was
        supported in a haphazard fashion using the authentication fields
        in the OSPF for IPv4 header.

        Another use for running multiple OSPF instances is if you want,
        for one reason or another, to have a single link belog to two or
        more OSPF areas.

        Support for multiple protocol instances on a link is
        accomplished via an "Instance ID" contained in the OSPF packet
        header and OSPF interface structures. Instance ID solely affects
        the reception of OSPF packets.

    2.5.  Use of link-local addresses

        On all interfaces except virtual links, OSPF packets are sent
        using the link-local interface address as source. A router
        learns the link-local interface addresses of all other routers
        attached to its links, and uses these addresses as next hop
        information for packet forwarding.

        On virtual links, global scope or site-local IP addresses must
        be used as the source for OSPF protocol packets.

    2.6.  Authentication changes

        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.

        When running over IPv6, OSPF relies on the IP Authentication
        Header (see [Ref19]) and the IP Encapsulating Security Payload
        (see [Ref20]) to ensure integrity and
        authentication/confidentiality of routing exchanges.





Coltun et al                                                    [Page 7]


Internet Draft               OSPF for IPv6                 February 1996


    2.7.  Packet format changes

        OSPF for IPv6 runs directly over IPv6. Aside from this, all
        addressing semantics have been removed from the OSPF packet
        headers, making it essentially "network-protocol independent".
        All addressing information is now contain in various LSA types
        only.

        In detail, changes in OSPF packet format consist of the
        following:

        o   The OSPF version number has been increased from 2 to 3.

        o   The Options field in Hello Packets and Database description
            Packets has been expanded to 24-bits.

        o   The Authentication and AuType fields have been removed from
            the OSPF packet header (see Section 2.6).

        o   The Hello packet now contains no address information at all,
            and includes a Interface ID which the originating router has
            assigned to uniquely identify (among its own interfaces) its
            interface to the link.  This Interface ID becomes the
            Network-LSA's Link State ID, should the router become
            Designated Router on the link.

        o   Two options bits have been added to the Options field for
            processing Router-LSAs during the SPF calculation (see
            Section A.2). The "V6-bit" allows routers to participate in
            OSPF topology distribution, but avoid the forwarding of IPv6
            datagrams. The "R-bit" allows nodes to participate in OSPF
            topology distribution, but avoid being used to forward
            transit traffic. This latter option could be used in multi-
            homed hosts that want to participate in routing
            calculations.

        o   The OSPF packet header now includes an "Instance ID" which
            allows multiple OSPF protocol instances to be run on a
            single link (see Section 2.4).

    2.8.  LSA format changes

        All addressing semantics have been removed from the LSA header,
        and from Router-LSAs and Network-LSAs. These two LSAs now
        describe the routing domain's topology in a network-protocol
        independent manner. New LSAs have been added to distribute IPv6
        address information, and data required for next hop resolution.
        The names of some of IPv4's LSAs have been changed to be more



Coltun et al                                                    [Page 8]


Internet Draft               OSPF for IPv6                 February 1996


        consistent with each other.

        In detail, changes in LSA format consist of the following:

        o   The Options field has been removed from the LSA header,
            expanded to 24 bits, and moved into the body of Router-LSAs,
            Network-LSAs, Inter-Area-Router-LSAs and Link-LSAs.

        o   The LSA Type field has been expanded (into the former
            Options space) to 16 bits, with the upper three bits
            encoding flooding scope and the handling of unknow LSA types
            (see Section 2.9).

        o   Addresses in LSAs are now expresses as [prefix, prefix
            length] instead of [address, mask] (see Section A.4.1). The
            default route is expressed as a prefix with length 0.

        o   The Router and Network LSAs now have no address information,
            and are network-protocol-independent.

        o   Router interface information may be spread across multiple
            Router LSAs. Receivers must concatenate all the Router-LSAs
            originated by a given router when running the SPF
            calculation.

        o   A new LSA called the Link-LSA has been introduced. The LSAs
            have local-link flooding scope; they are never flooded
            beyond the link that they are associated with. Link-LSAs
            have three purposes: 1) they provide the router's link-local
            address to all other routers attached to the link and 2)
            they inform other routers attached to the link of a list of
            IPv6 prefixes to associate with the link and 3) they allow
            the router to assert a collection of Options bits to
            associate with the Network-LSA that will be originated for
            the link. See Section A.4.8 for details.

        o   The Options field in the Network LSA is set to the logical
            OR of the Options that each router on the link advertises in
            its Link-LSA.

        o   Type-3 summary-LSAs have been renamed "Inter-Area-Prefix-
            LSAs". Type-4 summary LSAs have been renamed "Inter-Area-
            Router-LSAs".

        o   The Link State ID in Inter-Area-Prefix-LSAs, Inter-Area-
            Router-LSAs and AS-external-LSAs has lost its addressing
            semantics, and now serves solely to identify individual
            pieces of the Link State Database. All addresses or Router



Coltun et al                                                    [Page 9]


Internet Draft               OSPF for IPv6                 February 1996


            IDs that formerly were expressed by the Link State ID are
            now carried in the LSA bodies.

        o   Network-LSAs and Link-LSAs are the only LSAs whose Link
            State ID carries additional meaning. For these LSAs, the
            Link State ID is always the Interface ID of the originating
            router on the link being described. For this reason,
            Network-LSAs and Link-LSAs are now the only LSAs that cannot
            be broken into arbitrarily small pieces.

        o   A new LSA called the Inter-Area-Prefix-LSA has been
            introduced. This LSA carries all IPv6 prefix information
            that in IPv4 is included in Router-LSAs and Network-LSAs.
            See Section A.4.6 for details.

        o   Inclusion of a forwarding address in AS-external-LSAs is now
            optional. In addition, AS-external-LSAs can now reference
            another LSA, for inclusion of route attributes outside the
            scope of the OSPF protocol itself. For example, this can be
            used to attach tags to OSPF external routes as in [Ref5], or
            BGP path attributes as proposed in [Ref10].

    2.9.  Handling unknown LSA types

        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 (desirable for things like the proposed
        External Attributes LSA in [Ref10]). This behavior is explicitly
        coded in the LSA Handling bit of the link state header's LS type
        field (see Section A.4.2.1).

        The IPv4 OSPF behavior of simply discarding unknown types is
        unsupported due to the desire to mix router capabilities on a
        single link. Discarding unknown types causes problems when the
        Designated Router supports fewer options than the other routers
        on the link.

    2.10.  Removal of TOS

        The semantics of IPv4 TOS have not been moved forward to IPv6.
        Therfore, support for TOS in OSPF for IPv6 has been removed.
        This affects both LSA formats and routing calculations.

        The IPv6 header does have a 24-bit Flow Label field which may be
        used by a source to label those packets for which it requests
        special handling by IPv6 routers, such as non-default quality of
        service or "real-time" ser- vice. The OSPF LSAs for IPv6 have



Coltun et al                                                   [Page 10]


Internet Draft               OSPF for IPv6                 February 1996


        been organized so that future extensions to support routing
        based on Flow Label are possible.

3.  Implementation details

    To be written. Strategy will be to refer to IPv4 as much as
    possible. Only when changes are major is a section completely
    rewritten.











































Coltun et al                                                   [Page 11]


Internet Draft               OSPF for IPv6                 February 1996


References

    [Ref1]  Moy, J., "OSPF Version 2", Internet Draft, <draft-ietf-
            ospf-version2-06.txt>, Cascade, November 1995.

    [Ref2]  McKenzie, A., "ISO Transport Protocol specification ISO DP
            8073", RFC 905, ISO, April 1984.

    [Ref3]  McCloghrie, K., and M. Rose, "Management Information Base
            for network management of TCP/IP-based internets: MIB-II",
            STD 17, RFC 1213, Hughes LAN Systems, Performance Systems
            International, March 1991.

    [Ref4]  Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless
            Inter-Domain Routing (CIDR): an Address Assignment and
            Aggregation Strategy", RFC1519, BARRNet, cisco, MERIT,
            OARnet, September 1993.

    [Ref5]  Varadhan, K., S. Hares and Y. Rekhter, "BGP4/IDRP for IP---
            OSPF Interaction", RFC1745, December 1994

    [Ref6]  Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
            1700, USC/Information Sciences Institute, October 1994.

    [Ref7]  deSouza, O., and M. Rodrigues, "Guidelines for Running OSPF
            Over Frame Relay Networks", RFC 1586, March 1994.

    [Ref8]  Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon,
            Inc., March 1994.

    [Ref9]  Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587,
            RainbowBridge Communications, Stanford University, March
            1994.

    [Ref10] Ferguson, D., "The OSPF External Attributes LSA",
            unpublished.

    [Ref11] Moy, J., "Extending OSPF to Support Demand Circuits", RFC
            1793, Cascade, April 1995.

    [Ref12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
            DECWRL, Stanford University, November 1990.

    [Ref13] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-
            4)", RFC 1771, T.J. Watson Research Center, IBM Corp., cisco
            Systems, March 1995.





Coltun et al                                                   [Page 12]


Internet Draft               OSPF for IPv6                 February 1996


    [Ref14] Deering, S. and R. Hinden, "Internet Protocol, Version 6
            (IPv6) Specification", RFC 1883, Xerox PARC, Ipsilon
            Networks, December 1995.

    [Ref15] Deering, S. and R. Hinden, "IP Version 6 Addressing
            Architecture", RFC 1884, Xerox PARC, Ipsilon Networks,
            December 1995.

    [Ref16] Conta, A. and S. Deering, "Internet Control Message Protocol
            (ICMPv6) for the Internet Protocol Version 6 (IPv6)
            Specification" RFC 1885, Digital Equipment Corporation,
            Xerox PARC, December 1995.

    [Ref17] Narten, T., E. Nordmark and W. A. Simpson, "Neighbor
            Discovery for IP Version 6 (IPv6)", IBM, Sun Microsystems,
            work in progress.

    [Ref18] McCann, J. and S. Deering, "Path MTU Discovery for IP
            version 6", Digital Equipment Corporation, Xerox PARC, work
            in progress.

    [Ref19] Atkinson, R., "IP Authentication Header", RFC 1826, Naval
            Research Laboratory, August 1995.

    [Ref20] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC
            1827, Naval Research Laboratory, August 1995.

























Coltun et al                                                   [Page 13]


Internet Draft               OSPF for IPv6                 February 1996


A. OSPF data formats

    This appendix describes the format of OSPF protocol packets and OSPF
    LSAs.  The OSPF protocol runs directly over the IPv6 network layer.
    Before any data formats are described, the details of the OSPF
    encapsulation are explained.

    Next the OSPF Options field is described.  This field describes
    various capabilities that may or may not be supported by pieces of
    the OSPF routing domain. The OSPF Options field is contained in OSPF
    Hello packets, Database Description packets and in OSPF LSAs.

    OSPF packet formats are detailed in Section A.3.

    A description of OSPF LSAs appears in Section A.4. This section
    describes how IPv6 address prefixes are represented within LSAs,
    details the standard LSA header, and then provides formats for each
    of the specific LSA types.

A.1 Encapsulation of OSPF packets

    OSPF runs directly over the IPv6's network layer.  OSPF packets are
    therefore encapsulated solely by IPv6 and local data-link headers.

    OSPF does not define a way to fragment its protocol packets, and
    depends on IPv6 fragmentation when transmitting packets larger than
    the link MTU. If necessary, the length of OSPF packets can be up to
    65,535 bytes.  The OSPF packet types that are likely to be large
    (Database Description Packets, Link State Request, Link State
    Update, and Link State Acknowledgment packets) can usually be split
    into several separate protocol packets, without loss of
    functionality.  This is recommended; IPv6 fragmentation should be
    avoided whenever possible.  Using this reasoning, an attempt should
    be made to limit the sizes of OSPF packets sent over virtual links
    to 576 bytes unless Path MTU Discovery is being performed.

    The other important features of OSPF's IPv6 encapsulation are:

    o   Use of IPv6 multicast.  Some OSPF messages are multicast, when
        sent over broadcast networks.  Two distinct IP multicast
        addresses are used.  Packets sent to these multicast addresses
        should never be forwarded; they are meant to travel a single hop
        only. As such, the multicast addresses have been chosen with
        link-local scope, and packets sent to these addresses should
        have their IPv6 Hop Limit set to 1.

        AllSPFRouters
            This multicast address has been assigned the value FF02::5.



Coltun et al                                                   [Page 14]


Internet Draft               OSPF for IPv6                 February 1996


            All routers running OSPF should be prepared to receive
            packets sent to this address.  Hello packets are always sent
            to this destination.  Also, certain OSPF protocol packets
            are sent to this address during the flooding procedure.

        AllDRouters
            This multicast address has been assigned the value FF02::6.
            Both the Designated Router and Backup Designated Router must
            be prepared to receive packets destined to this address.
            Certain OSPF protocol packets are sent to this address
            during the flooding procedure.

    o   OSPF is IP protocol 89.  This number should be inserted in the
        Next Header field of the enapsulating IPv6 header.

    o   Routing protocol packets are sent with IPv6 Priority field set
        to 7 (internet control traffic).  OSPF protocol packets should
        be given precedence over regular IPv6 data traffic, in both
        sending and receiving.
































Coltun et al                                                   [Page 15]


Internet Draft               OSPF for IPv6                 February 1996


A.2 The Options field

    The 24-bit OSPF Options field is present in OSPF Hello packets,
    Database Description packets and certain LSAs (router-LSAs,
    network-LSAs, inter-area-router-LSAs and link-LSAs). The Options
    field enables OSPF routers to support (or not support) optional
    capabilities, and to communicate their capability level to other
    OSPF routers.  Through this mechanism routers of differing
    capabilities can be mixed within an OSPF routing domain.

    When used in Hello packets, the Options field allows a router to
    reject a neighbor because of a capability mismatch.  Alternatively,
    when capabilities are exchanged in Database Description packets a
    router can choose not to forward certain LSAs to a neighbor because
    of its reduced functionality.  Lastly, listing capabilities in LSAs
    allows routers to forward data traffic around reduced functionality
    routers, by excluding them from parts of the routing table
    calculation.

    Six bits of the OSPF Options field have been assigned. Each bit is
    described briefly below. Routers should reset (i.e.  clear)
    unrecognized bits in the Options field when sending Hello packets or
    Database Description packets and when originating LSAs. Conversely,
    routers encountering unrecognized Option bits in received Hello
    Packets, Database Description packets or LSAs should ignore the
    capability and process the packet/LSA normally.

                            1                     2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8  9  0  1  2  3
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+
       | | | | | | | | | | | | | | | | | | |DC| R| N|MC| E|V6|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+

                             The Options field


    V6-bit
        The bit indicates whether the router/link should be included in
        IPv6 routing calculations. See Section XXXX of this memo.

    E-bit
        This bit describes the way AS-external-LSAs are flooded, as
        described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [Ref1].

    MC-bit
        This bit describes whether IP multicast datagrams are forwarded
        according to the specifications in [Ref7].




Coltun et al                                                   [Page 16]


Internet Draft               OSPF for IPv6                 February 1996


    N-bit
        This bit describes the handling of Type-7 LSAs, as specified in
        [Ref8].

    R-bit
        This bit (the `Router' bit) indicates whether the originator is
        an active router.  If the router bit is clear routes which
        transit the advertising node may not be computed. Clearing the
        router bit would be appropriate for a multi-homed host that
        wants to participate in routing, but does not want to forward
        non-locally addressed packets.  See Section XXXX of this memo.

    DC-bit
        This bit describes the router's handling of demand circuits, as
        specified in [Ref10].




































Coltun et al                                                   [Page 17]


Internet Draft               OSPF for IPv6                 February 1996


A.3 OSPF Packet Formats

    There are five distinct OSPF packet types.  All OSPF packet types
    begin with a standard 20 byte header.  This header is described
    first.  Each packet type is then described in a succeeding section.
    In these sections each packet's division into fields is displayed,
    and then the field definitions are enumerated.

    All OSPF packet types (other than the OSPF Hello packets) deal with
    lists of LSAs.  For example, Link State Update packets implement the
    flooding of LSAs throughout the OSPF routing domain. The format of
    LSAs is described in Section A.4.

    The receive processing of OSPF packets is detailed in Section XXXX.
    The sending of OSPF packets is explained in Section XXXX.




































Coltun et al                                                   [Page 18]


Internet Draft               OSPF for IPv6                 February 1996


A.3.1 The OSPF packet header

    Every OSPF packet starts with a standard 20 byte header. Together
    with the encapsulating IPv6 headers, the OSPF header contains all
    the information necessary to determine whether the packet should be
    accepted for further processing.  This determination is described in
    Section XXXX of this memo.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Version #   |     Type      |         Packet length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Router ID                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Area ID                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Checksum            |  Instance ID  |      0        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



    Version #
        The OSPF version number.  This specification documents version 3
        of the OSPF protocol.

    Type
        The OSPF packet types are as follows. See Sections A.3.2 through
        A.3.6 for details.



                          Type   Description
                          ________________________________
                          1      Hello
                          2      Database Description
                          3      Link State Request
                          4      Link State Update
                          5      Link State Acknowledgment




    Packet length
        The length of the OSPF protocol packet in bytes.  This length
        includes the standard OSPF header.




Coltun et al                                                   [Page 19]


Internet Draft               OSPF for IPv6                 February 1996


    Router ID
        The Router ID of the packet's source.

    Area ID
        A 32 bit number identifying the area that this packet belongs
        to.  All OSPF packets are associated with a single area.  Most
        travel a single hop only.  Packets travelling over a virtual
        link are labelled with the backbone Area ID of 0.

    Checksum
        The standard IP checksum of the entire contents of the packet,
        starting with the OSPF packet header. This checksum is
        calculated as the 16-bit one's complement of the one's
        complement sum of all the 16-bit words in the packet.  If the
        packet's length is not an integral number of 16-bit words, the
        packet is padded with a byte of zero before checksumming.

    Instance ID
        Enables multiple instances of OSPF to be run over a single link.
        Each protocol instance would be assigned a separate Instance ID;
        the Instance ID has local link significance only. Received
        packets whose Instance ID is not equal to the receiving
        interface's Instance ID are discarded.

    0   These fields are reserved.  They must be 0.


























Coltun et al                                                   [Page 20]


Internet Draft               OSPF for IPv6                 February 1996


A.3.2 The Hello packet

    Hello packets are OSPF packet type 1.  These packets are sent
    periodically on all interfaces (including virtual links) in order to
    establish and maintain neighbor relationships.  In addition, Hello
    Packets are multicast on those links having a multicast or broadcast
    capability, enabling dynamic discovery of neighboring routers.

    All routers connected to a common link must agree on certain
    parameters (HelloInterval and RouterDeadInterval).  These parameters
    are included in Hello packets, so that differences can inhibit the
    forming of neighbor relationships. The Hello packet also contains
    fields used in Designated Router election (Designated Router ID and
    Backup Designated Router ID), and fields used to detect bi-
    directionality (the Router IDs of all neighbors whose Hellos have
    been recently received).


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Version #   |       1       |         Packet length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Router ID                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Area ID                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Checksum            |  Instance ID  |      0        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Interface ID                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Rtr Pri    |              Options                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         HelloInterval         |        RouterDeadInterval     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Designated Router ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Backup Designated Router ID                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Neighbor ID                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |



    Interface ID
        32-bit number uniquely identifying this interface among the
        collection of this router's interfaces. For example, in some



Coltun et al                                                   [Page 21]


Internet Draft               OSPF for IPv6                 February 1996


        implementations it may be possible to use the MIB-II IfIndex.

    Rtr Pri
        This router's Router Priority.  Used in (Backup) Designated
        Router election.  If set to 0, the router will be ineligible to
        become (Backup) Designated Router.

    Options
        The optional capabilities supported by the router, as documented
        in Section A.2.

    HelloInterval
        The number of seconds between this router's Hello packets.

    RouterDeadInterval
        The number of seconds before declaring a silent router down.

    Designated Router ID
        The identity of the Designated Router for this network, in the
        view of the sending router.  The Designated Router is identified
        by its Router ID. Set to 0.0.0.0 if there is no Designated
        Router.

    Backup Designated Router ID
        The identity of the Backup Designated Router for this network,
        in the view of the sending router.  The Backup Designated Router
        is identified by its IP Router ID.  Set to 0.0.0.0 if there is
        no Backup Designated Router.

    Neighbor ID
        The Router IDs of each router from whom valid Hello packets have
        been seen recently on the network.  Recently means in the last
        RouterDeadInterval seconds.


















Coltun et al                                                   [Page 22]


Internet Draft               OSPF for IPv6                 February 1996


A.3.3 The Database Description packet

    Database Description packets are OSPF packet type 2.  These packets
    are exchanged when an adjacency is being initialized.  They describe
    the contents of the link-state database.  Multiple packets may be
    used to describe the database.  For this purpose a poll-response
    procedure is used.  One of the routers is designated to be the
    master, the other the slave.  The master sends Database Description
    packets (polls) which are acknowledged by Database Description
    packets sent by the slave (responses).  The responses are linked to
    the polls via the packets' DD sequence numbers.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Version #   |       2       |         Packet length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Router ID                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Area ID                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Checksum            |  Instance ID  |      0        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0|0|0|0|0|I|M|MS              Options                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     DD sequence number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +-                                                             -+
       |                                                               |
       +-                      An LSA Header                          -+
       |                                                               |
       +-                                                             -+
       |                                                               |
       +-                                                             -+
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |


    The format of the Database Description packet is very similar to
    both the Link State Request and Link State Acknowledgment packets.
    The main part of all three is a list of items, each item describing
    a piece of the link-state database.  The sending of Database
    Description Packets is documented in Section 10.8 of [Ref1].  The
    reception of Database Description packets is documented in Section
    10.6 of [Ref1].



Coltun et al                                                   [Page 23]


Internet Draft               OSPF for IPv6                 February 1996


    I-bit
        The Init bit.  When set to 1, this packet is the first in the
        sequence of Database Description Packets.

    M-bit
        The More bit.  When set to 1, it indicates that more Database
        Description Packets are to follow.

    MS-bit
        The Master/Slave bit.  When set to 1, it indicates that the
        router is the master during the Database Exchange process.
        Otherwise, the router is the slave.

    Options
        The optional capabilities supported by the router, as documented
        in Section A.2.

    DD sequence number
        Used to sequence the collection of Database Description Packets.
        The initial value (indicated by the Init bit being set) should
        be unique.  The DD sequence number then increments until the
        complete database description has been sent.


    The rest of the packet consists of a (possibly partial) list of the
    link-state database's pieces.  Each LSA in the database is described
    by its LSA header.  The LSA header is documented in Section A.4.1.
    It contains all the information required to uniquely identify both
    the LSA and the LSA's current instance.






















Coltun et al                                                   [Page 24]


Internet Draft               OSPF for IPv6                 February 1996


A.3.4 The Link State Request packet

    Link State Request packets are OSPF packet type 3.  After exchanging
    Database Description packets with a neighboring router, a router may
    find that parts of its link-state database are out-of-date.  The
    Link State Request packet is used to request the pieces of the
    neighbor's database that are more up-to-date.  Multiple Link State
    Request packets may need to be used.

    A router that sends a Link State Request packet has in mind the
    precise instance of the database pieces it is requesting. Each
    instance is defined by its LS sequence number, LS checksum, and LS
    age, although these fields are not specified in the Link State
    Request Packet itself.  The router may receive even more recent
    instances in response.

    The sending of Link State Request packets is documented in Section
    10.9 of [Ref1].  The reception of Link State Request packets is
    documented in Section 10.7 of [Ref1].


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Version #   |       3       |         Packet length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Router ID                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Area ID                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Checksum            |  Instance ID  |      0        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               0               |           LS type             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Link State ID                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Advertising Router                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |


    Each LSA requested is specified by its LS type, Link State ID, and
    Advertising Router.  This uniquely identifies the LSA, but not its
    instance.  Link State Request packets are understood to be requests
    for the most recent instance (whatever that might be).






Coltun et al                                                   [Page 25]


Internet Draft               OSPF for IPv6                 February 1996


A.3.5 The Link State Update packet

    Link State Update packets are OSPF packet type 4.  These packets
    implement the flooding of LSAs.  Each Link State Update packet
    carries a collection of LSAs one hop further from their origin.
    Several LSAs may be included in a single packet.

    Link State Update packets are multicast on those physical networks
    that support multicast/broadcast.  In order to make the flooding
    procedure reliable, flooded LSAs are acknowledged in Link State
    Acknowledgment packets.  If retransmission of certain LSAs is
    necessary, the retransmitted LSAs are always carried by unicast Link
    State Update packets. For more information on the reliable flooding
    of LSAs, consult Section XXXX.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Version #   |       4       |         Packet length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Router ID                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Area ID                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Checksum            |  Instance ID  |      0        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            # LSAs                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +-                                                            +-+
       |                             LSAs                              |
       +-                                                            +-+
       |                              ...                              |



    # LSAs
        The number of LSAs included in this update.


    The body of the Link State Update packet consists of a list of LSAs.
    Each LSA begins with a common 20 byte header, described in Section
    A.4.2. Detailed formats of the different types of LSAs are described
    in Section A.4.






Coltun et al                                                   [Page 26]


Internet Draft               OSPF for IPv6                 February 1996


A.3.6 The Link State Acknowledgment packet

    Link State Acknowledgment Packets are OSPF packet type 5.  To make
    the flooding of LSAs reliable, flooded LSAs are explicitly
    acknowledged.  This acknowledgment is accomplished through the
    sending and receiving of Link State Acknowledgment packets.
    Multiple LSAs can be acknowledged in a single Link State
    Acknowledgment packet.

    Depending on the state of the sending interface and the sender of
    the corresponding Link State Update packet, a Link State
    Acknowledgment packet is sent either to the multicast address
    AllSPFRouters, to the multicast address AllDRouters, or as a
    unicast.  The sending of Link State Acknowledgement packets is
    documented in Section 13.5 of [Ref1].  The reception of Link State
    Acknowledgement packets is documented in Section 13.7 of [Ref1].

    The format of this packet is similar to that of the Data Description
    packet.  The body of both packets is simply a list of LSA headers.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Version #   |       5       |         Packet length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Router ID                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Area ID                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Checksum            |  Instance ID  |      0        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +-                                                             -+
       |                                                               |
       +-                         An LSA Header                       -+
       |                                                               |
       +-                                                             -+
       |                                                               |
       +-                                                             -+
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |


    Each acknowledged LSA is described by its LSA header.  The LSA
    header is documented in Section A.4.2.  It contains all the
    information required to uniquely identify both the LSA and the LSA's



Coltun et al                                                   [Page 27]


Internet Draft               OSPF for IPv6                 February 1996


    current instance.


















































Coltun et al                                                   [Page 28]


Internet Draft               OSPF for IPv6                 February 1996


A.4 LSA formats

    This memo defines seven distinct types of LSAs.  Each LSA begins
    with a standard 20 byte LSA header.  This header is explained in
    Section A.4.2.  Succeeding sections then diagram the separate LSA
    types.

    Each LSA describes a piece of the OSPF routing domain.  Every router
    originates a router-LSA. A network-LSA is advertised for each link
    by its Designated Router. A router's link-local addresses are
    advertised to its neighbors in link-LSAs. IPv6 prefixes are
    advertised in intra-area-prefix-LSAs, inter-area-prefix-LSAs and
    AS-external-LSAs.  Location of specific routers can be advertised
    across area boundaries in inter-area-router-LSAs. All LSAs are then
    flooded throughout the OSPF routing domain.  The flooding algorithm
    is reliable, ensuring that all routers have the same collection of
    LSAs.  (See Section XXXX for more information concerning the
    flooding algorithm).  This collection of LSAs is called the link-
    state database.

    From the link state database, each router constructs a shortest path
    tree with itself as root.  This yields a routing table (see Section
    11 of [Ref1]).  For the details of the routing table build process,
    see Section XXXX.



























Coltun et al                                                   [Page 29]


Internet Draft               OSPF for IPv6                 February 1996


A.4.1 IPv6 Prefix Representation

    IPv6 address prefixes are always represented by a PrefixLength,
    representing the length in bits of the significant part of the
    prefix (value 0 - 128 inclusive), an 8-bit PrefixOptions field, and
    then a variable amount of prefix information.  The prefix
    information is always an even multiple of 32-bit words long, and is
    padded with zero bits to the next 32-bit word boundary.  The length
    of the prefix information, in 32-bit words, is therefore
    ((PrefixLength + 31) / 32).

    The default route is represented by a prefix of length 0.







































Coltun et al                                                   [Page 30]


Internet Draft               OSPF for IPv6                 February 1996


A.4.1.1 Prefix Options

    Each prefix is advertised along with an 8-bit field of capabilities.
    These serve as input to the various routing calculations, allowing,
    for example, certain prefixes to be ignored in some cases, or to be
    marked as not readvertisable in others.

                       0  1  2  3  4  5  6  7
                      +--+--+--+--+--+--+--+--+
                      |  |  |  |  | P|MC|LA|NU|
                      +--+--+--+--+--+--+--+--+

                          The Prefix Options field


    NU-bit
        The "no unicast" capability bit. If set, the prefix should be
        excluded from IPv6 unicast calculations, otherwise it should be
        included.

    LA-bit
        The "local address" capability bit. If set, the prefix is
        actually an IPv6 interface address of the advertising router.

    MC-bit
        The "multicast" capability bit. If set, the prefix should be
        included in IPv6 multicast routing calculations, otherwise it
        should be excluded.

    P-bit
        The "propagate" bit. Set on NSSA area prefixes that should be
        readvertised at the NSSA area border.



















Coltun et al                                                   [Page 31]


Internet Draft               OSPF for IPv6                 February 1996


A.4.2 The LSA header

    All LSAs begin with a common 20 byte header.  This header contains
    enough information to uniquely identify the LSA (LS type, Link State
    ID, and Advertising Router).  Multiple instances of the LSA may
    exist in the routing domain at the same time.  It is then necessary
    to determine which instance is more recent.  This is accomplished by
    examining the LS age, LS sequence number and LS checksum fields that
    are also contained in the LSA header.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            LS age             |           LS type             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Link State ID                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Advertising Router                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     LS sequence number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



    LS age
        The time in seconds since the LSA was originated.

    LS type
        The type of the LSA.  Each LSA type has a separate advertisement
        format. See Section A.4.2.1 for a detailed description of LS
        type.

    Link State ID
        Together with LS type and Advertising Router, uniquely
        identifies the LSA in the link-state database.

    Advertising Router
        The Router ID of the router that originated the LSA.  For
        example, in network-LSAs this field is equal to the Router ID of
        the network's Designated Router.

    LS sequence number
        Detects old or duplicate LSAs.  Successive instances of an LSA
        are given successive LS sequence numbers.  See Section 12.1.6 in
        [Ref1] for more details.



Coltun et al                                                   [Page 32]


Internet Draft               OSPF for IPv6                 February 1996


    LS checksum
        The Fletcher checksum of the complete contents of the LSA,
        including the LSA header but excluding the LS age field. See
        Section 12.1.7 in [Ref1] for more details.

    length
        The length in bytes of the LSA.  This includes the 20 byte LSA
        header.











































Coltun et al                                                   [Page 33]


Internet Draft               OSPF for IPv6                 February 1996


A.4.2.1 LS type

    The LS type field indicates the function performed by the LSA.  The
    high-order three bits of LS type encode generic properties of the
    LSA, while the remainder (called LSA function code) indicate the
    LSA's specific functionality. The format of the LS type is as
    follows:

                                      1
        0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |U |S2|S1|           LSA Function Code          |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

    The U bit indicates how the LSA should be handled by a router which
    does not recognize its function code.  Its values are:



          U-bit   LSA Handling
          ____________________________________________________________
          0       Store and flood the LSA, as if type understood
          1       Treat the LSA as if it had link-local flooding scope



    The S1 and S2 bits indicate the flooding scope of the LSA.  The
    values are:



    S2   S1   Flooding Scope
    _______________________________________________________________________
    0    0    Link-Local Scoping. Flooded only on link it is originated on.
    0    1    Area Scoping. Flooded to all routers in the originating area
    1    0    AS Scoping. Flooded to all routers in the AS
    1    1    Reserved




    The LSA function codes are defined as follows. The origination and
    processing of these LSA function codes are defined elsewhere in this
    memo, except for the group-membership-LSA (see [Ref7]) and the
    Type-7-LSA (see [Ref8]). Each LSA function code also implies a
    specific setting for the U, S1 and S2 bits, as shown below.





Coltun et al                                                   [Page 34]


Internet Draft               OSPF for IPv6                 February 1996



              LSA function code   LS Type   Description
              ___________________________________________________
              1                   0x2001    Router-LSA
              2                   0x2002    Network-LSA
              3                   0x2003    Inter-Area-Prefix-LSA
              4                   0x2004    Inter-Area-Router-LSA
              5                   0x4005    AS-External-LSA
              6                   0x2006    Group-membership-LSA
              7                   0x2007    Type-7-LSA
              8                   0x0008    Link-LSA
              9                   0x2009    Intra-Area-Prefix-LSA







































Coltun et al                                                   [Page 35]


Internet Draft               OSPF for IPv6                 February 1996


A.4.3 Router-LSAs

    Router-LSAs have LS type equal to 0x2001.  Each router in an area
    originates one or more router-LSAs.  The complete collection of
    router-LSAs originated by the router describe the state and cost of
    the router's interfaces to the area. For details concerning the
    construction of router-LSAs, see Section XXXX. Router-LSAs are
    flooded throughout a single area only.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            LS age             |0|0|1|          1              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Link State ID                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Advertising Router                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     LS sequence number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    0    |V|E|B|             Options                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |       0       |           Metric              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Interface ID                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Neighbor Interface ID                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Neighbor Router ID                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |       0       |           Metric              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Interface ID                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Neighbor Interface ID                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Neighbor Router ID                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |


    A single router may originate one or more Router LSAs, distinguished
    by their Link-State IDs (which are chosen arbitrarily by the



Coltun et al                                                   [Page 36]


Internet Draft               OSPF for IPv6                 February 1996


    originating router).  The Options field and V, E and B bits should
    be the same in all Router LSAs from a single originator.  However,
    in the case of a mismatch the values in the LSA with the lowest Link
    State ID take precedence. When more than one Router LSA is received
    from a single router, the links are processed as if concatenated
    into a single LSA.


    bit V
        When set, the router is an endpoint of one or more fully
        adjacent virtual links having the described area as Transit area
        (V is for virtual link endpoint).

    bit E
        When set, the router is an AS boundary router (E is for
        external).

    bit B
        When set, the router is an area border router (B is for border).

    Options
        The optional capabilities supported by the router, as documented
        in Section A.2.


    The following fields are used to describe each router interface.
    The Type field indicates the kind of interface being described.  It
    may be an interface to a transit network, a point-to-point
    connection to another router or a virtual link.  The values of all
    the other fields describing a router interface depend on the
    interface's Type field.


    Type
        The kind of interface being described.  One of the following:



                 Type   Description
                 __________________________________________________
                 1      Point-to-point connection to another router
                 2      Connection to a transit network
                 3      Reserved
                 4      Virtual link







Coltun et al                                                   [Page 37]


Internet Draft               OSPF for IPv6                 February 1996


    Metric
        The cost of using this router interface, for outbound traffic.

    Interface ID
        The Interface ID assigned to the interface being described. See
        Sections XXXX and C.3.

    Neighbor Interface ID
        The Interface ID the neighbor router (or the attached link's
        Designated Router, for Type 2 interfaces) has been advertising
        in hello packets sent on the atached link. n

    Neighbor Router ID
        The Router ID the neighbor router (or the attached link's
        Designated Router, for Type 2 interfaces).

        For Type 2 links, the combination of Neighbor Interface ID and
        Neighbor Router ID allows the network-LSA for the attached link
        to be found in the link-state database.
































Coltun et al                                                   [Page 38]


Internet Draft               OSPF for IPv6                 February 1996


A.4.4 Network-LSAs

    Network-LSAs have LS type equal to 0x2002.  A network-LSA is
    originated for each broadcast and NBMA link in the area which
    supports two or more routers.  The network-LSA is originated by the
    link's Designated Router.  The LSA describes all routers attached to
    the link, including the Designated Router itself.  The LSA's Link
    State ID field is set to the Interface ID that the Designated Router
    has been advertising in Hello packets on the link.

    The distance from the network to all attached routers is zero.  This
    is why the metric fields need not be specified in the network-LSA.
    For details concerning the construction of network-LSAs, see Section
    XXXX.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            LS age             |0|0|1|          2              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Link State ID                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Advertising Router                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     LS sequence number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      0        |              Options                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Attached Router                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |



    Attached Router
        The Router IDs of each of the routers attached to the link.
        Actually, only those routers that are fully adjacent to the
        Designated Router are listed.  The Designated Router includes
        itself in this list.  The number of routers included can be
        deduced from the LSA header's length field.








Coltun et al                                                   [Page 39]


Internet Draft               OSPF for IPv6                 February 1996


A.4.5 Inter-Area-Prefix-LSAs

    Inter-Area-Prefix-LSAs have LS type equal to 0x2003.  These LSAs are
    originated by area border routers, and describe routes to IPv6
    address prefixes that belong to other areas. A separate Inter-Area-
    Prefix-LSA is originated for each IPv6 address prefix. For details
    concerning the construction of Inter-Area-Prefix-LSAs, see Section
    XXXX.

    For stub areas, Inter-Area-Prefix-LSAs can also be used to describe
    a (per-area) default route.  Default summary routes are used in stub
    areas instead of flooding a complete set of external routes.  When
    describing a default summary route, the Inter-Area-Prefix-LSA's
    PrefixLength is set to 0.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            LS age             |0|0|1|          3              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Link State ID                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Advertising Router                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     LS sequence number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      0        |                  Metric                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | PrefixLength  | PrefixOptions |              (0)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Address Prefix                        |
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Metric
        The cost of this route.  Expressed in the same units as the
        interface costs in the router-LSAs. When the Inter-Area-Prefix-
        LSA is describing a route to a range of addresses (see Section
        C.2) the cost is set to the maximum cost to any reachable
        component of the address range.

    PrefixLength, PrefixOptions and Address Prefix
        Representation of the IPv6 address prefix, as described in
        Section A.4.1.



Coltun et al                                                   [Page 40]


Internet Draft               OSPF for IPv6                 February 1996


A.4.6 Inter-Area-Router-LSAs

    Inter-Area-Router-LSAs have LS type equal to 0x2004.  These LSAs are
    originated by area border routers, and describe routes to routers in
    other areas.  (To see why it is necessary to advertise the location
    of each ASBR, consult Section 16.4 in [Ref1].)  Each LSA describes a
    route to a single router. For details concerning the construction of
    Inter-Area-Router-LSAs, see Section XXXX.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            LS age             |0|0|1|        4                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Link State ID                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Advertising Router                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     LS sequence number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      0        |                  Options                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      0        |                  Metric                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Destination Router ID                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Options
        The optional capabilities supported by the router, as documented
        in Section A.2.

    Metric
        The cost of this route.  Expressed in the same units as the
        interface costs in the router-LSAs.

    Destination Router ID
        The Router ID of the router being described by the LSA.










Coltun et al                                                   [Page 41]


Internet Draft               OSPF for IPv6                 February 1996


A.4.7 AS-external-LSAs

    AS-external-LSAs have LS type equal to 0x2005.  These LSAs are
    originated by AS boundary routers, and describe destinations
    external to the AS. Each LSA describes a route to a single IPv6
    address prefix. For details concerning the construction of AS-
    external-LSAs, see Section XXXX.

    AS-external-LSAs can be used to describe a default route.  Default
    routes are used when no specific route exists to the destination.
    When describing a default route, the AS-external-LSA's PrefixLength
    is set to 0.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            LS age             |0|0|1|          5              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Link State ID                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Advertising Router                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     LS sequence number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           |E|F|                 Metric                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | PrefixLength  | PrefixOptions |     Referenced LS Type        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Address Prefix                        |
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +-                                                             -+
       |                                                               |
       +-                 Forwarding Address (Optional)               -+
       |                                                               |
       +-                                                             -+
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Referenced Link State ID (Optional)            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    bit E
        The type of external metric.  If bit E is set, the metric



Coltun et al                                                   [Page 42]


Internet Draft               OSPF for IPv6                 February 1996


        specified is a Type 2 external metric.  This means the metric is
        considered larger than any intra-AS path.  If bit E is zero, the
        specified metric is a Type 1 external metric.  This means that
        it is expressed in the same units as the link state metric
        (i.e., the same units as interface cost).

    bit F
        If set, a forwarding address has been included in the LSA.

    Metric
        The cost of this route.  Interpretation depends on the external
        type indication (bit E above).

    PrefixLength, PrefixOptions and Address Prefix
        Representation of the IPv6 address prefix, as described in
        Section A.4.1.

    Referenced LS type
        If non-zero, an LSA with this LS type is to be associated with
        this LSA (see Referenced Link State ID below).

    Forwarding address
        A fully qualified IPv6 address (128 bits).  Included in the LSA
        if and only if bit F has been set.  If included, Data traffic
        for the advertised destination and TOS will be forwarded to this
        address. Must not be set to the IPv6 Unspecified Address
        (0:0:0:0:0:0:0:0).

    Referenced Link State ID
        Included if and only if Reference LS Type is non-zero.  If
        included, additional information concerning the advertised
        external route can be found in the LSA having LS type equal to
        "Referenced LS Type", Link State ID equal to "Referenced Link
        State ID" and Advertising Router the same as that specified in
        the AS-external-LSA's link state header. This additional
        information is not used by the OSPF protocol itself.  It may be
        used to communicate information between AS boundary routers; the
        precise nature of such information is outside the scope of this
        specification.

    If Forwarding address and Referenced Link State ID are both included
    in the AS-external-LSA, Forwarding Address always comes first.









Coltun et al                                                   [Page 43]


Internet Draft               OSPF for IPv6                 February 1996


A.4.8 Link-LSAs

    Link-LSAs have LS type equal to 0x0008.  A router originates a
    separate Link-LSA for each link it is attached to. These LSAs have
    local-link flooding scope; they are never flooded beyond the link
    that they are associated with. Link-LSAs have three purposes: 1)
    they provide the router's link-local address to all other routers
    attached to the link and 2) they inform other routers attached to
    the link of a list of IPv6 prefixes to associate with the link and
    3) they allow the router to assert a collection of Options bits to
    associate with the Network-LSA that will be originated for the link.

    A link-LSA's Link State ID is set equal to the originating router's
    Interface ID on the link.
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            LS age             |0|0|0|           8             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Link State ID                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Advertising Router                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      LS sequence number                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Rtr Pri    |                 Options                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +-                                                             -+
       |                                                               |
       +-                 Link-local Interface Address                -+
       |                                                               |
       +-                                                             -+
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          # prefixes                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  PrefixLength | PrefixOptions |              (0)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Address Prefix                        |
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  PrefixLength | PrefixOptions |              (0)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Coltun et al                                                   [Page 44]


Internet Draft               OSPF for IPv6                 February 1996


       |                         Address Prefix                        |
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Rtr Pri
        The Router Priority of the interface attaching the originating
        router to the link.

    Options
        The set of Options bits that the router would like set in the
        Network-LSA that will be originated for the link.

    Link-local Interface Address
        The originating router's link-local interface address on the
        link.

    # prefixes
        The number of IPv6 address prefixes contained in the LSA.

    The rest of the link-LSA contains a list of IPv6 prefixes to be
    associated with the link.

    PrefixLength, PrefixOptions and Address Prefix
        Representation of an IPv6 address prefix, as described in
        Section A.4.1.


























Coltun et al                                                   [Page 45]


Internet Draft               OSPF for IPv6                 February 1996


A.4.9 Intra-Area-Prefix-LSAs

    Intra-Area-Prefix-LSAs have LS type equal to 0x2009. Intra-Area-
    Prefix-LSAs allow a router to associate one or more IPv6 address
    prefixes with a router (itself) or a transit link (one of the
    originating router's attached links). These prefixes are then
    processed as "stub links" during the OSPF intra-area routing
    calculation (see Section XXXX).

    A router can originate multiple Intra-Area-Prefix-LSAs for each
    router or transit network; each such LSA is distinguished by its
    Link State ID.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            LS age             |0|0|1|            9            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Link State ID                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Advertising Router                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     LS sequence number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          # prefixes           |     Referenced LS type        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Referenced Link State ID                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Referenced Advertising Router                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  PrefixLength | PrefixOptions |           Metric              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Address Prefix                         |
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  PrefixLength | PrefixOptions |           Metric              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Address Prefix                         |
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    # prefixes
        The number of IPv6 address prefixes contained in the LSA.




Coltun et al                                                   [Page 46]


Internet Draft               OSPF for IPv6                 February 1996


    Referenced LS type, Referenced Link State ID and Referenced
        Advertising Router" Identifies the router-LSA or network-LSA
        with which the IPv6 address prefixes should be associated. If
        Referenced LS type is 1, the prefixes are associated with a
        router-LSA, Referenced Link State ID should be 0 and Referenced
        Advertising Router should be the originating router's Router ID.
        If Referenced LS type is 2, the prefixes are associated with a
        network-LSA, Referenced Link State ID should be the Interface ID
        of the link's Designated Router and Referenced Advertising
        Router should be the Designated Router's Router ID.

    The rest of the Intra-Area-Prefix-LSA contains a list of IPv6
    prefixes to be associated with the router or transit link, together
    with the cost of each prefix.

    PrefixLength, PrefixOptions and Address Prefix
        Representation of an IPv6 address prefix, as described in
        Section A.4.1.

    Metric
        The cost of this prefix.  Expressed in the same units as the
        interface costs in the router-LSAs.





























Coltun et al                                                   [Page 47]


Internet Draft               OSPF for IPv6                 February 1996


B. Architectural Constants

    Architectural coonstants for the OSPF protocol are defined in
    Appendix C of [Ref1]. The only difference for OSPF for IPv6 is that
    DefaultDestination is encoded as a prefix of length 0 (see Section
    A.4.1).

C. Configurable Constants

    The OSPF protocol has quite a few configurable parameters.  These
    parameters are listed below.  They are grouped into general
    functional categories (area parameters, interface parameters, etc.).
    Sample values are given for some of the parameters.

    Some parameter settings need to be consistent among groups of
    routers.  For example, all routers in an area must agree on that
    area's parameters, and all routers attached to a network must agree
    on that network's HelloInterval and RouterDeadInterval.

    Some parameters may be determined by router algorithms outside of
    this specification (e.g., the address of a host connected to the
    router via a SLIP line).  From OSPF's point of view, these items are
    still configurable.

    C.1 Global parameters

        In general, a separate copy of the OSPF protocol is run for each
        area.  Because of this, most configuration parameters are
        defined on a per-area basis.  The few global configuration
        parameters are listed below.


        Router ID
            This is a 32-bit number that uniquely identifies the router
            in the Autonomous System. If a router's OSPF Router ID is
            changed, the router's OSPF software should be restarted
            before the new Router ID takes effect. Before restarting in
            order to change its Router ID, the router should flush its
            self-originated LSAs from the routing domain (see Section
            14.1 of [Ref1]), or they will persist for up to MaxAge
            minutes.

    C.2 Area parameters

        All routers belonging to an area must agree on that area's
        configuration.  Disagreements between two routers will lead to
        an inability for adjacencies to form between them, with a
        resulting hindrance to the flow of routing protocol and data



Coltun et al                                                   [Page 48]


Internet Draft               OSPF for IPv6                 February 1996


        traffic.  The following items must be configured for an area:


        Area ID
            This is a 32-bit number that identifies the area.  The Area
            ID of 0 is reserved for the backbone.

        List of address ranges
            Address ranges control the advertisement of routes across
            area boundaries. Each address range consists of the
            following items:

            [IPv6 prefix, prefix length]
                    Describes the collection of IPv6 addresses contained
                    in the address range.

            Status  Set to either Advertise or DoNotAdvertise.  Routing
                    information is condensed at area boundaries.
                    External to the area, at most a single route is
                    advertised (via a inter-area-prefix-LSA) for each
                    address range. The route is advertised if and only
                    if the address range's Status is set to Advertise.
                    Unadvertised ranges allow the existence of certain
                    networks to be intentionally hidden from other
                    areas. Status is set to Advertise by default.

        ExternalRoutingCapability
            Whether AS-external-LSAs will be flooded into/throughout the
            area.  If AS-external-LSAs are excluded from the area, the
            area is called a "stub".  Internal to stub areas, routing to
            external destinations will be based solely on a default
            inter-area route.  The backbone cannot be configured as a
            stub area.  Also, virtual links cannot be configured through
            stub areas.  For more information, see Section 3.6 of
            [Ref1].

        StubDefaultCost
            If the area has been configured as a stub area, and the
            router itself is an area border router, then the
            StubDefaultCost indicates the cost of the default inter-
            area-prefix-LSA that the router should advertise into the
            area. See Section XXXX for more information.

    C.3 Router interface parameters

        Some of the configurable router interface parameters (such as
        Area ID, HelloInterval and RouterDeadInterval) actually imply
        properties of the attached links, and therefore must be



Coltun et al                                                   [Page 49]


Internet Draft               OSPF for IPv6                 February 1996


        consistent across all the routers attached to that link.  The
        parameters that must be configured for a router interface are:


        IPv6 link-local address
            The IPv6 link-local address associated with this interface.
            May be learned through auto-configuration.

        Area ID
            The OSPF area to which the attached link belongs.

        Instance ID
            The OSPF protocol instance associated with this OSPF
            interface. Defaults to 0.

        Interface ID
            32-bit number uniquely identifying this interface among the
            collection of this router's interfaces. For example, in some
            implementations it may be possible to use the MIB-II
            IfIndex.

        IPv6 prefixes
            The list of IPv6 prefixes to associate with the link. These
            will be advertised in intra-area-prefix-LSAs.

        Interface output cost(s)
            The cost of sending a packet on the interface, expressed in
            the link state metric.  This is advertised as the link cost
            for this interface in the router's router-LSA. The interface
            output cost must always be greater than 0.

        RxmtInterval
            The number of seconds between LSA retransmissions, for
            adjacencies belonging to this interface.  Also used when
            retransmitting Database Description and Link State Request
            Packets.  This should be well over the expected round-trip
            delay between any two routers on the attached link.  The
            setting of this value should be conservative or needless
            retransmissions will result.  Sample value for a local area
            network: 5 seconds.

        InfTransDelay
            The estimated number of seconds it takes to transmit a Link
            State Update Packet over this interface.  LSAs contained in
            the update packet must have their age incremented by this
            amount before transmission.  This value should take into
            account the transmission and propagation delays of the
            interface.  It must be greater than 0.  Sample value for a



Coltun et al                                                   [Page 50]


Internet Draft               OSPF for IPv6                 February 1996


            local area network: 1 second.

        Router Priority
            An 8-bit unsigned integer.  When two routers attached to a
            network both attempt to become Designated Router, the one
            with the highest Router Priority takes precedence.  If there
            is still a tie, the router with the highest Router ID takes
            precedence.  A router whose Router Priority is set to 0 is
            ineligible to become Designated Router on the attached link.
            Router Priority is only configured for interfaces to
            broadcast and NBMA networks.

        HelloInterval
            The length of time, in seconds, between the Hello Packets
            that the router sends on the interface.  This value is
            advertised in the router's Hello Packets.  It must be the
            same for all routers attached to a common link.  The smaller
            the HelloInterval, the faster topological changes will be
            detected; however, more OSPF routing protocol traffic will
            ensue.  Sample value for a X.25 PDN: 30 seconds.  Sample
            value for a local area network (LAN): 10 seconds.

        RouterDeadInterval
            After ceasing to hear a router's Hello Packets, the number
            of seconds before its neighbors declare the router down.
            This is also advertised in the router's Hello Packets in
            their RouterDeadInterval field.  This should be some
            multiple of the HelloInterval (say 4).  This value again
            must be the same for all routers attached to a common link.

    C.4 Virtual link parameters

        Virtual links are used to restore/increase connectivity of the
        backbone.  Virtual links may be configured between any pair of
        area border routers having interfaces to a common (non-backbone)
        area.  The virtual link appears as an unnumbered point-to-point
        link in the graph for the backbone.  The virtual link must be
        configured in both of the area border routers.

        A virtual link appears in router-LSAs (for the backbone) as if
        it were a separate router interface to the backbone.  As such,
        it has most of the parameters associated with a router interface
        (see Section C.3).  Virtual links do not have link-local
        addresses, but instead use one of the router's global-scope or
        site-local IPv6 addresses as the IP source in OSPF protocol
        packets it sends along the virtual link.  Router Priority is not
        used on virtual links. Interface output cost is not configured
        on virtual links, but is dynamically set to be the cost of the



Coltun et al                                                   [Page 51]


Internet Draft               OSPF for IPv6                 February 1996


        intra-area path between the two endpoint routers.  The parameter
        RxmtInterval must be configured, and should be well over the
        expected round-trip delay between the two routers.  This may be
        hard to estimate for a virtual link; it is better to err on the
        side of making it too large.

        A virtual link is defined by the following two configurable
        parameters: the Router ID of the virtual link's other endpoint,
        and the (non-backbone) area through which the virtual link runs
        (referred to as the virtual link's Transit area).  Virtual links
        cannot be configured through stub areas.

    C.5 NBMA network parameters

        OSPF treats an NBMA network much like it treats a broadcast
        network.  Since there may be many routers attached to the
        network, a Designated Router is selected for the network.  This
        Designated Router then originates a network-LSA, which lists all
        routers attached to the NBMA network.

        However, due to the lack of broadcast capabilities, it may be
        necessary to use configuration parameters in the Designated
        Router selection.  These parameters will only need to be
        configured in those routers that are themselves eligible to
        become Designated Router (i.e., those router's whose Router
        Priority for the network is non-zero), and then only if no
        automatic procedure for discovering neighbors exists:


        List of all other attached routers
            The list of all other routers attached to the NBMA network.
            Each router is configured with its Router ID and IPv6 link-
            local address on the network.  Also, for each router listed,
            that router's eligibility to become Designated Router must
            be defined.  When an interface to a NBMA network comes up,
            the router sends Hello Packets only to those neighbors
            eligible to become Designated Router, until the identity of
            the Designated Router is discovered.

        PollInterval
            If a neighboring router has become inactive (Hello Packets
            have not been seen for RouterDeadInterval seconds), it may
            still be necessary to send Hello Packets to the dead
            neighbor.  These Hello Packets will be sent at the reduced
            rate PollInterval, which should be much larger than
            HelloInterval.  Sample value for a PDN X.25 network: 2
            minutes.




Coltun et al                                                   [Page 52]


Internet Draft               OSPF for IPv6                 February 1996


    C.6 Point-to-MultiPoint network parameters

        On Point-to-MultiPoint networks, it may be necessary to
        configure the set of neighbors that are directly reachable over
        the Point-to-MultiPoint network. Each neighbor is configured
        with its Router ID and IPv6 link-local address on the network.
        Designated Routers are not elected on Point-to-MultiPoint
        networks, so the Designated Router eligibility of configured
        neighbors is undefined.

    C.7 Host route parameters

        Host routes are advertised in intra-area-prefix-LSAs as fully
        qualified IPv6 prefixes (i.e., prefix length set equal to 128
        bits).  They indicate either router interfaces to point-to-point
        networks, looped router interfaces, or IPv6 hosts that are
        directly connected to the router (e.g., via a PPP connection).
        For each host directly connected to the router, the following
        items must be configured:


        Host IPv6 address
            The IPv6 address of the host.

        Cost of link to host
            The cost of sending a packet to the host, in terms of the
            link state metric. However, since the host probably has only
            a single connection to the internet, the actual configured
            cost(s) in many cases is unimportant (i.e., will have no
            effect on routing).

        Area ID
            The OSPF area to which the host belongs.


















Coltun et al                                                   [Page 53]


Internet Draft               OSPF for IPv6                 February 1996


Security Considerations

    When running over IPv6, OSPF relies on the IP Authentication Header
    (see [Ref19]) and the IP Encapsulating Security Payload (see
    [Ref120]) to ensure integrity and authentication/confidentiality of
    routing exchanges.

Authors Addresses

    Rob Coltun
    FORE Systems
    Phone: (301) 571-2521
    email: rcoltun@fore.com

    Dennis Ferguson
    Ipsilon Networks
    dennis@Ipsilon.COM

    John Moy
    Cascade Communications Corp.
    5 Carlisle Road
    Westford, MA 01886
    Phone: 508-952-1367
    Fax:   508-692-9214
    Email: jmoy@casc.com

    This document expires in August 1996.
























Coltun et al                                                   [Page 54]