GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc2740

Network Working Group R. Coltun Requests for Comments: 2740 Siara Systems Category: Standards Track D. Ferguson

                                                      Juniper Networks
                                                                J. Moy
                                                     Sycamore Networks
                                                         December 1999
                           OSPF for IPv6

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (1999).  All Rights Reserved.

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 on 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.
 Most packets in OSPF for IPv6 are almost as compact as those in OSPF
 for IPv4, even with the larger IPv6 addresses. Most field-XSand
 packet-size limitations present in OSPF for IPv4 have been relaxed.
 In addition, option handling has been made more flexible.

Coltun, et al. Standards Track [Page 1] RFC 2740 OSPF for IPv6 December 1999

 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.

Table of Contents

 1        Introduction ........................................... 4
 1.1      Terminology ............................................ 4
 2        Differences from OSPF for IPv4 ......................... 4
 2.1      Protocol processing per-link, not per-subnet ........... 5
 2.2      Removal of addressing semantics ........................ 5
 2.3      Addition of Flooding scope ............................. 5
 2.4      Explicit support for multiple instances per link ....... 6
 2.5      Use of link-local addresses ............................ 6
 2.6      Authentication changes ................................. 7
 2.7      Packet format changes .................................. 7
 2.8      LSA format changes ..................................... 8
 2.9      Handling unknown LSA types ............................ 10
 2.10     Stub area support ..................................... 10
 2.11     Identifying neighbors by Router ID .................... 11
 3        Implementation details ................................ 11
 3.1      Protocol data structures .............................. 12
 3.1.1    The Area Data structure ............................... 13
 3.1.2    The Interface Data structure .......................... 13
 3.1.3    The Neighbor Data Structure ........................... 14
 3.2      Protocol Packet Processing ............................ 15
 3.2.1    Sending protocol packets .............................. 15
 3.2.1.1  Sending Hello packets ................................. 16
 3.2.1.2  Sending Database Description Packets .................. 17
 3.2.2    Receiving protocol packets ............................ 17
 3.2.2.1  Receiving Hello Packets ............................... 19
 3.3      The Routing table Structure ........................... 19
 3.3.1    Routing table lookup .................................. 20
 3.4      Link State Advertisements ............................. 20
 3.4.1    The LSA Header ........................................ 21
 3.4.2    The link-state database ............................... 22
 3.4.3    Originating LSAs ...................................... 22
 3.4.3.1  Router-LSAs ........................................... 25
 3.4.3.2  Network-LSAs .......................................... 27
 3.4.3.3  Inter-Area-Prefix-LSAs ................................ 28
 3.4.3.4  Inter-Area-Router-LSAs ................................ 29
 3.4.3.5  AS-external-LSAs ...................................... 29
 3.4.3.6  Link-LSAs ............................................. 31
 3.4.3.7  Intra-Area-Prefix-LSAs ................................ 32
 3.5      Flooding .............................................. 35
 3.5.1    Receiving Link State Update packets ................... 36
 3.5.2    Sending Link State Update packets ..................... 36
 3.5.3    Installing LSAs in the database ....................... 38

Coltun, et al. Standards Track [Page 2] RFC 2740 OSPF for IPv6 December 1999

 3.6      Definition of self-originated LSAs .................... 39
 3.7      Virtual links ......................................... 39
 3.8      Routing table calculation ............................. 39
 3.8.1    Calculating the shortest path tree for an area ........ 40
 3.8.1.1  The next hop calculation .............................. 41
 3.8.2    Calculating the inter-area routes ..................... 42
 3.8.3    Examining transit areas' summary-LSAs ................. 42
 3.8.4    Calculating AS external routes ........................ 42
 3.9      Multiple interfaces to a single link .................. 43
          References ............................................ 44
 A        OSPF data formats ..................................... 46
 A.1      Encapsulation of OSPF packets ......................... 46
 A.2      The Options field ..................................... 47
 A.3      OSPF Packet Formats ................................... 48
 A.3.1    The OSPF packet header ................................ 49
 A.3.2    The Hello packet ...................................... 50
 A.3.3    The Database Description packet ....................... 52
 A.3.4    The Link State Request packet ......................... 54
 A.3.5    The Link State Update packet .......................... 55
 A.3.6    The Link State Acknowledgment packet .................. 56
 A.4      LSA formats ........................................... 57
 A.4.1    IPv6 Prefix Representation ............................ 58
 A.4.1.1  Prefix Options ........................................ 58
 A.4.2    The LSA header ........................................ 59
 A.4.2.1  LS type ............................................... 60
 A.4.3    Router-LSAs ........................................... 61
 A.4.4    Network-LSAs .......................................... 64
 A.4.5    Inter-Area-Prefix-LSAs ................................ 65
 A.4.6    Inter-Area-Router-LSAs ................................ 66
 A.4.7    AS-external-LSAs ...................................... 67
 A.4.8    Link-LSAs ............................................. 69
 A.4.9    Intra-Area-Prefix-LSAs ................................ 71
 B        Architectural Constants ............................... 73
 C        Configurable Constants ................................ 73
 C.1      Global parameters ..................................... 73
 C.2      Area parameters ....................................... 74
 C.3      Router interface parameters ........................... 75
 C.4      Virtual link parameters ............................... 77
 C.5      NBMA network parameters ............................... 77
 C.6      Point-to-MultiPoint network parameters ................ 78
 C.7      Host route parameters ................................. 78
          Security Considerations ............................... 79
          Authors' Addresses .................................... 79
          Full Copyright Statement .............................. 80

Coltun, et al. Standards Track [Page 3] RFC 2740 OSPF for IPv6 December 1999

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 between 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].

Coltun, et al. Standards Track [Page 4] RFC 2740 OSPF for IPv6 December 1999

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 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
 an 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 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:

Coltun, et al. Standards Track [Page 5] RFC 2740 OSPF for IPv6 December 1999

 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.
 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 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 belong 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

 IPv6 link-local addresses are for use on a single link, for purposes
 of neighbor discovery, auto-configuration, etc. IPv6 routers do not
 forward IPv6 datagrams having link-local source addresses [Ref15].
 Link-local unicast addresses are assigned from the IPv6 address range
 FF80/10.
 OSPF for IPv6 assumes that each router has been assigned link-local
 unicast addresses on each of the router's attached physical segments.
 On all OSPF interfaces except virtual links, OSPF packets are sent
 using the interface's associated link-local unicast address as
 source.  A router learns the link-local addresses of all other
 routers attached to its links, and uses these addresses as next hop
 information during packet forwarding.
 On virtual links, global scope or site-local IP addresses must be
 used as the source for OSPF protocol packets.

Coltun, et al. Standards Track [Page 6] RFC 2740 OSPF for IPv6 December 1999

 Link-local addresses appear in OSPF Link-LSAs (see Section 3.4.3.6).
 However, link-local addresses are not allowed in other OSPF LSA
 types.  In particular, link-local addresses must not be advertised in
 inter-area-prefix-LSAs (Section 3.4.3.3), AS-external-LSAs (Section
 3.4.3.5) or intra-area-prefix-LSAs (Section 3.4.3.7).

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.
 Protection of OSPF packet exchanges against accidental data
 corruption is provided by the standard IPv6 16-bit one's complement
 checksum, covering the entire OSPF packet and prepended IPv6 pseudo-
 header (see Section A.3.1).

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 contained in the 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 Packet
    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 an 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 Netowrk-LSA's Link State
    ID, should the router become Designated-Router on the link.

Coltun, et al. Standards Track [Page 7] RFC 2740 OSPF for IPv6 December 1999

 o  Two option bits, the "R-bit" and the "V6-bit", have been added to
    the  Options field for processing Router-LSAs during the SPF
    calculation (see Section A.2).  If the "R-bit" is clear an OSPF
    speaker can participate in OSPF topology distribution without
    being used to forward transit traffic; this can be used in multi-
    homed hosts that want to participate in the routing protocol. The
    V6-bit specializes the R-bit; if the V6-bit is clear an OSPF
    speaker can participate in OSPF topology distribution without
    being used to forward IPv6 datagrams. If the R-bit is set and the
    V6-bit is clear, IPv6 datagrams are not forwarded but diagrams
    belonging to another protocol family may be forwarded.
 o  TheOSPF 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 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. See Section A.2 for details.
 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 unknown LSA types (see Section 2.9).
 o  Addresses in LSAs are now expressed 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.

Coltun, et al. Standards Track [Page 8] RFC 2740 OSPF for IPv6 December 1999

 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, 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.
    In IPv4, the router-LSA carries a router's IPv4 interface
    addresses, the IPv4 equivalent of link-local addresses.  These are
    only used when calculating next hops during the OSPF routing
    calculation (see Section 16.1.1 of [Ref1]), so they do not need to
    be flooded past the local link; hence using link-LSAs to
    distribute these addresses is more efficient. Note that link-local
    addresses cannot be learned through the reception of Hellos in all
    cases: on NBMA links next hop routers do not necessarily exchange
    hellos, but rather learn of each other's existence by way of the
    Designated Router.
 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 IDs that were formerly 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 whose size cannot be limited: a Network-LSA must
    list all routers connected to the link, and a Link-LSA must list
    all of a router's addresses on the link.
 o  A new LSA called the Intra-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.9 for
    details.

Coltun, et al. Standards Track [Page 9] RFC 2740 OSPF for IPv6 December 1999

 o  Inclusion of a forwarding address in AS-external-LSAs is now
    optional, as is the inclusion of an external route tag (see
    [Ref5]). In addition, AS-external-LSAs can now reference another
    LSA, for inclusion of additional route attributes that are outside
    the scope of the OSPF protocol itself. For example, this can be
    used to attach BGP path attributes to external routes 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. Stub area support

 In OSPF for IPv4, stub areas were designed to minimize link-state
 database and routing table sizes for the areas' internal routers.
 This allows routers with minimal resources to participate in even
 very large OSPF routing domains.
 In OSPF for IPv6, the concept of stub areas is retained. In IPv6, of
 the mandatory LSA types, stub areas carry only router-LSAs, network-
 LSAs, Inter-Area-Prefix-LSAs, Link-LSAs, and Intra-Area-Prefix-LSAs.
 This is the IPv6 equivalent of the LSA types carried in IPv4 stub
 areas: router-LSAs, network-LSAs and type 3 summary-LSAs.
 However, unlike in IPv4, IPv6 allows LSAs with unrecognized LS types
 to be labeled "Store and flood the LSA, as if type understood" (see
 the U-bit in Section A.4.2.1). Uncontrolled introduction of such LSAs
 could cause a stub area's link-state database to grow larger than its
 component routers' capacities.
 To guard against this, the following rule regarding stub areas has
 been established: an LSA whose LS type is unrecognized may only be
 flooded into/throughout a stub area if both a) the LSA has area or
 link-local flooding scope and b) the LSA has U-bit set to 0. See
 Section 3.5 for details.

Coltun, et al. Standards Track [Page 10] RFC 2740 OSPF for IPv6 December 1999

2.11. Identifying neighbors by Router ID

 In OSPF for IPv6, neighboring routers on a given link are always
 identified by their OSPF Router ID. This contrasts with the IPv4
 behavior where neighbors on point-to-point networks and virtual links
 are identified by their Router IDs, and neighbors on broadcast, NBMA
 and Point-to-MultiPoint links are identified by their IPv4 interface
 addresses.
 This change affects the reception of OSPF packets (see Section 8.2 of
 [Ref1]), the lookup of neighbors (Section 10 of [Ref1]) and the
 reception of Hello Packets (Section 10.5 of [Ref1]).
 The Router ID of 0.0.0.0 is reserved, and should not be used.

3. Implementation details

 When going from IPv4 to IPv6, the basic OSPF mechanisms remain
 unchanged from those documented in [Ref1]. These mechanisms are
 briefly outlined in Section 4 of [Ref1]. Both IPv6 and IPv4 have a
 link-state database composed of LSAs and synchronized between
 adjacent routers. Initial synchronization is performed through the
 Database Exchange process, through the exchange of Database
 Description, Link State Request and Link State Update packets.
 Thereafter database synchronization is maintained via flooding,
 utilizing Link State Update and Link State Acknowledgment packets.
 Both IPv6 and IPv4 use OSPF Hello Packets to discover and maintain
 neighbor relationships, and to elect Designated Routers and Backup
 Designated Routers on broadcast and NBMA links. The decision as to
 which neighbor relationships become adjacencies, along with the basic
 ideas behind inter-area routing, importing external information in
 AS-external-LSAs and the various routing calculations are also the
 same.
 In particular, the following IPv4 OSPF functionality described in
 [Ref1] remains completely unchanged for IPv6:
 o  Both IPv4 and IPv6 use OSPF packet types described in Section 4.3
    of [Ref1], namely: Hello, Database Description, Link State
    Request, Link State Update and Link State Acknowledgment packets.
    While in some cases (e.g., Hello packets) their format has changed
    somewhat, the functions of the various packet types remains the
    same.
 o  The system requirements for an OSPF implementation remain
    unchanged, although OSPF for IPv6 requires an IPv6 protocol stack
    (from the network layer on down) since it runs directly over the
    IPv6 network layer.

Coltun, et al. Standards Track [Page 11] RFC 2740 OSPF for IPv6 December 1999

 o  The discovery and maintenance of neighbor relationships, and the
    selection and establishment of adjacencies remain the same. This
    includes election of the Designated Router and Backup Designated
    Router on broadcast and NBMA links. These mechanisms are described
    in Sections 7, 7.1, 7.2, 7.3, 7.4 and 7.5 of [Ref1].
 o  The link types (or equivalently, interface types) supported by
    OSPF remain unchanged, namely: point-to-point, broadcast, NBMA,
    Point-to-MultiPoint and virtual links.
 o  The interface state machine, including the list of OSPF interface
    states and events, and the Designated Router and Backup Designated
    Router election algorithm, remain unchanged.  These are described
    in Sections 9.1, 9.2, 9.3 and 9.4 of [Ref1].
 o  The neighbor state machine, including the list of OSPF neighbor
    states and events, remain unchanged. These are described in
    Sections 10.1, 10.2, 10.3 and 10.4 of [Ref1].
 o  Aging of the link-state database, as well as flushing LSAs from
    the routing domain through the premature aging process, remains
    unchanged from the description in Sections 14 and 14.1 of [Ref1].
 However, some OSPF protocol mechanisms have changed, as outlined in
 Section 2 above. These changes are explained in detail in the
 following subsections, making references to the appropriate sections
 of [Ref1].
 The following subsections provide a recipe for turning an IPv4 OSPF
 implementation into an IPv6 OSPF implementation.

3.1. Protocol data structures

 The major OSPF data structures are the same for both IPv4 and IPv6:
 areas, interfaces, neighbors, the link-state database and the routing
 table. The top-level data structures for IPv6 remain those listed in
 Section 5 of [Ref1], with the following modifications:
 o  All LSAs with known LS type and AS flooding scope appear in the
    top-level data structure, instead of belonging to a specific area
    or link. AS-external-LSAs are the only LSAs defined by this
    specification which have AS flooding scope.  LSAs with unknown LS
    type, U-bit set to 1 (flood even when unrecognized) and AS
    flooding scope also appear in the top-level data structure.

Coltun, et al. Standards Track [Page 12] RFC 2740 OSPF for IPv6 December 1999

3.1.1. The Area Data structure

 The IPv6 area data structure contains all elements defined for IPv4
 areas in Section 6 of [Ref1]. In addition, all LSAs of known type
 which have area flooding scope are contained in the IPv6 area data
 structure. This always includes the following LSA types: router-LSAs,
 network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs and
 intra-area-prefix-LSAs. LSAs with unknown LS type, U-bit set to 1
 (flood even when unrecognized) and area scope also appear in the area
 data structure. IPv6 routers implementing MOSPF add group-
 membership-LSAs to the area data structure. Type-7-LSAs belong to an
 NSSA area's data structure.

3.1.2. The Interface Data structure

 In OSPF for IPv6, an interface connects a router to a link.  The IPv6
 interface structure modifies the IPv4 interface structure (as defined
 in Section 9 of [Ref1]) as follows:
 Interface ID
    Every interface is assigned an Interface ID, which uniquely
    identifies the interface with the router. For example, some
    implementations may be able to use the MIB-II IfIndex ([Ref3]) as
    Interface ID. The Interface ID appears in Hello packets sent out
    the interface, the link-local-LSA originated by router for the
    attached link, and the router-LSA originated by the router-LSA for
    the associated area. It will also serve as the Link State ID for
    the network-LSA that the router will originate for the link if the
    router is elected Designated Router.
 Instance ID
    Every interface is assigned an Instance ID. This should default to
    0, and is only necessary to assign differently on those links that
    will contain multiple separate communities of OSPF Routers. For
    example, suppose that there are two communities of routers on a
    given ethernet segment that you wish to keep separate.
    The first community is given an Instance ID of 0, by assigning 0
    as the Instance ID of all its routers' interfaces to the ethernet.
    An Instance ID of 1 is assigned to the other routers' interfaces
    to the ethernet. The OSPF transmit and receive processing (see
    Section 3.2) will then keep the two communities separate.
 List of LSAs with link-local scope
    All LSAs with link-local scope and which were originated/flooded
    on the link belong to the interface structure which connects to
    the link. This includes the collection of the link's link-LSAs.

Coltun, et al. Standards Track [Page 13] RFC 2740 OSPF for IPv6 December 1999

 List of LSAs with unknown LS type
    All LSAs with unknown LS type and U-bit set to 0 (if unrecognized,
    treat the LSA as if it had link-local flooding scope) are kept in
    the data structure for the interface that received the LSA.
 IP interface address
    For IPv6, the IPv6 address appearing in the source of OSPF packets
    sent out the interface is almost always a link-local address. The
    one exception is for virtual links, which must use one of the
    router's own site-local or global IPv6 addresses as IP interface
    address.
 List of link prefixes
    A list of IPv6 prefixes can be configured for the attached link.
    These will be advertised by the router in link-LSAs, so that they
    can be advertised by the link's Designated Router in intra-area-
    prefix-LSAs.
 In OSPF for IPv6, each router interface has a single metric,
 representing the cost of sending packets out the interface.  In
 addition, OSPF for IPv6 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.  For that reason, AuType and Authentication key are not
 associated with IPv6 OSPF interfaces.
 Interface states, events, and the interface state machine remain
 unchanged from IPv4, and are documented in Sections 9.1, 9.2 and 9.3
 of [Ref1] respectively. The Designated Router and Backup Designated
 Router election algorithm also remains unchanged from the IPv4
 election in Section 9.4 of [Ref1].

3.1.3. The Neighbor Data Structure

 The neighbor structure performs the same function in both IPv6 and
 IPv4. Namely, it collects all information required to form an
 adjacency between two routers, if an adjacency becomes necessary.
 Each neighbor structure is bound to a single OSPF interface. The
 differences between the IPv6 neighbor structure and the neighbor
 structure defined for IPv4 in Section 10 of [Ref1] are:
 Neighbor's Interface ID
    The Interface ID that the neighbor advertises in its Hello Packets
    must be recorded in the neighbor structure. The router will
    include the neighbor's Interface ID in the router's router-LSA
    when either a) advertising a point-to-point link to the neighbor
    or b) advertising a link to a network where the neighbor has
    become Designated Router.

Coltun, et al. Standards Track [Page 14] RFC 2740 OSPF for IPv6 December 1999

 Neighbor IP address
    Except on virtual links, the neighbor's IP address will be an IPv6
    link-local address.
 Neighbor's Designated Router
    The neighbor's choice of Designated Router is now encoded as a
    Router ID, instead of as an IP address.
 Neighbor's Backup Designated Router
    The neighbor's choice of Designated Router is now encoded as a
    Router ID, instead of as an IP address.
 Neighbor states, events, and the neighbor state machine remain
 unchanged from IPv4, and are documented in Sections 10.1, 10.2 and
 10.3 of [Ref1] respectively. The decision as to which adjacencies to
 form also remains unchanged from the IPv4 logic documented in Section
 10.4 of [Ref1].

3.2. Protocol Packet Processing

 OSPF for IPv6 runs directly over IPv6's network layer. As such, it is
 encapsulated in one or more IPv6 headers, with the Next Header field
 of the immediately encapsulating IPv6 header set to the value 89.
 As for IPv4, in IPv6 OSPF routing protocol packets are sent along
 adjacencies only (with the exception of Hello packets, which are used
 to discover the adjacencies). OSPF packet types and functions are the
 same in both IPv4 and IPv4, encoded by the
 Type field of the standard OSPF packet header.

3.2.1. Sending protocol packets

 When an IPv6 router sends an OSPF routing protocol packet, it fills
 in the fields of the standard OSPF for IPv6 packet header (see
 Section A.3.1) as follows:
 Version #
    Set to 3, the version number of the protocol as documented in this
    specification.
 Type
    The type of OSPF packet, such as Link state Update or Hello
    Packet.
 Packet length
    The length of the entire OSPF packet in bytes, including the
    standard OSPF packet header.

Coltun, et al. Standards Track [Page 15] RFC 2740 OSPF for IPv6 December 1999

 Router ID
    The identity of the router itself (who is originating the packet).
 Area ID
    The OSPF area that the packet is being sent into.
 Instance ID
    The OSPF Instance ID associated with the interface that the packet
    is being sent out of.
 Checksum
    The standard IPv6 16-bit one's complement checksum, covering the
    entire OSPF packet and prepended IPv6 pseudo-header (see Section
    A.3.1).
 Selection of OSPF routing protocol packets' IPv6 source and
 destination addresses is performed identically to the IPv4 logic in
 Section 8.1 of [Ref1]. The IPv6 destination address is chosen from
 among the addresses AllSPFRouters, AllDRouters and the Neighbor IP
 address associated with the other end of the adjacency (which in
 IPv6, for all links except virtual links, is an IPv6 link-local
 address).
 The sending of Link State Request Packets and Link State
 Acknowledgment Packets remains unchanged from the IPv4 procedures
 documented in Sections 10.9 and 13.5 of [Ref1] respectively. Sending
 Hello Packets is documented in Section 3.2.1.1, and the sending of
 Database Description Packets in Section 3.2.1.2. The sending of Link
 State Update Packets is documented in Section 3.5.2.

3.2.1.1. Sending Hello packets

 IPv6 changes the way OSPF Hello packets are sent in the following
 ways (compare to Section 9.5 of [Ref1]):
 o  Before the Hello Packet is sent out an interface, the interface's
    Interface ID must be copied into the Hello Packet.
 o  The Hello Packet no longer contains an IP network mask, as OSPF
    for IPv6 runs per-link instead of per-subnet.
 o  The choice of Designated Router and Backup Designated Router are
    now indicated within Hellos by their Router IDs, instead of by
    their IP interface addresses.      Advertising the Designated
    Router (or Backup Designated Router) as 0.0.0.0 indicates that the
    Designated Router (or Backup Designated Router) has not yet been
    chosen.

Coltun, et al. Standards Track [Page 16] RFC 2740 OSPF for IPv6 December 1999

 o  The Options field within Hello packets has moved around, getting
    larger in the process. More options bits are now possible. Those
    that must be set correctly in Hello packets are: The E-bit is set
    if and only if the interface attaches to a non-stub area, the N-
    bit is set if and only if the interface attaches to an NSSA area
    (see [Ref9]), and the DC- bit is set if and only if the router
    wishes to suppress the sending of future Hellos over the interface
    (see [Ref11]). Unrecognized bits in the Hello Packet's Options
    field should be cleared.
 Sending Hello packets on NBMA networks proceeds for IPv6 in exactly
 the same way as for IPv4, as documented in Section 9.5.1 of [Ref1].

3.2.1.2. Sending Database Description Packets

 The sending of Database Description packets differs from Section 10.8
 of [Ref1] in the following ways:
 o  The Options field within Database Description packets has moved
    around, getting larger in the process. More options bits are now
    possible. Those that must be set correctly in Database Description
    packets are: The MC-bit is set if and only if the router is
    forwarding multicast datagrams according to the MOSPF
    specification in [Ref7], and the DC-bit is set if and only if the
    router wishes to suppress the sending of Hellos over the interface
    (see [Ref11]).  Unrecognized bits in the Database Description
    Packet's Options field should be cleared.

3.2.2. Receiving protocol packets

 Whenever an OSPF protocol packet is received by the router it is
 marked with the interface it was received on.  For routers that have
 virtual links configured, it may not be immediately obvious which
 interface to associate the packet with.  For example, consider the
 Router RT11 depicted in Figure 6 of [Ref1].  If RT11 receives an OSPF
 protocol packet on its interface to Network N8, it may want to
 associate the packet with the interface to Area 2, or with the
 virtual link to Router RT10 (which is part of the backbone).      In
 the following, we assume that the packet is initially associated with
 the non-virtual link.
 In order for the packet to be passed to OSPF for processing, the
 following tests must be performed on the encapsulating IPv6 headers:
 o  The packet's IP destination address must be one of the IPv6
    unicast addresses associated with the receiving interface (this
    includes link-local addresses), or one of the IP multicast
    addresses AllSPFRouters or AllDRouters.

Coltun, et al. Standards Track [Page 17] RFC 2740 OSPF for IPv6 December 1999

 o  The Next Header field of the immediately encapsulating IPv6 header
    must specify the OSPF protocol (89).
 o  Any encapsulating IP Authentication Headers (see [Ref19]) and the
    IP Encapsulating Security Payloads (see [Ref20]) must be processed
    and/or verified to ensure integrity and
    authentication/confidentiality of OSPF routing exchanges.
 o  Locally originated packets should not be passed on to OSPF.  That
    is, the source IPv6 address should be examined to make sure this
    is not a multicast packet that the router itself generated.
 After processing the encapsulating IPv6 headers, the OSPF packet
 header is processed.  The fields specified in the header must match
 those configured for the receiving interface.  If they do not, the
 packet should be discarded:
 o  The version number field must specify protocol version 3.
 o  The standard IPv6 16-bit one's complement checksum, covering the
    entire OSPF packet and prepended IPv6 pseudo-header, must be
    verified (see Section A.3.1).
 o  The Area ID found in the OSPF header must be verified.  If both of
    the following cases fail, the packet should be discarded.  The
    Area ID specified in the header must either:
    (1)   Match the Area ID of the receiving interface. In
          this case, unlike for IPv4, the IPv6 source
          address is not restricted to lie on the same IP
          subnet as the receiving interface. IPv6 OSPF runs
          per-link, instead of per-IP-subnet.
    (2)   Indicate the backbone.  In this case, the packet
          has been sent over a virtual link.  The receiving
          router must be an area border router, and the
          Router ID specified in the packet (the source
          router) must be the other end of a configured
          virtual link.  The receiving interface must also
          attach to the virtual link's configured Transit
          area.  If all of these checks succeed, the packet
          is accepted and is from now on associated with
          the virtual link (and the backbone area).
 o  The Instance ID specified in the OSPF header must match the
    receiving interface's Instance ID.

Coltun, et al. Standards Track [Page 18] RFC 2740 OSPF for IPv6 December 1999

 o  Packets whose IP destination is AllDRouters should only be
    accepted if the state of the receiving interface is DR or Backup
    (see Section 9.1).
 After header processing, the packet is further processed according to
 its OSPF packet type.  OSPF packet types and functions are the same
 for both IPv4 and IPv6.
 If the packet type is Hello, it should then be further processed by
 the Hello Protocol.  All other packet types are sent/received only on
 adjacencies.  This means that the packet must have been sent by one
 of the router's active neighbors. The neighbor is identified by the
 Router ID appearing the the received packet's OSPF header. Packets
 not matching any active neighbor are discarded.
 The receive processing of Database Description Packets, Link State
 Request Packets and Link State Acknowledgment Packets remains
 unchanged from the IPv4 procedures documented in Sections 10.6, 10.7
 and 13.7 of [Ref1] respectively. The receiving of Hello Packets is
 documented in Section 3.2.2.1, and the receiving of Link State Update
 Packets is documented in Section 3.5.1.

3.2.2.1. Receiving Hello Packets

 The receive processing of Hello Packets differs from Section 10.5 of
 [Ref1] in the following ways:
 o  On all link types (e.g., broadcast, NBMA, point-to- point, etc),
    neighbors are identified solely by their OSPF Router ID. For all
    link types except virtual links, the Neighbor IP address is set to
    the IPv6 source address in the IPv6 header of the received OSPF
    Hello packet.
 o There is no longer a Network Mask field in the Hello Packet.
 o  The neighbor's choice of Designated Router and Backup Designated
    Router is now encoded as an OSPF Router ID instead of an IP
    interface address.

3.3. The Routing table Structure

 The routing table used by OSPF for IPv4 is defined in Section 11 of
 [Ref1]. For IPv6 there are analogous routing table entries: there are
 routing table entries for IPv6 address prefixes, and also for AS
 boundary routers. The latter routing table entries are only used to
 hold intermediate results during the routing table build process (see
 Section 3.8).

Coltun, et al. Standards Track [Page 19] RFC 2740 OSPF for IPv6 December 1999

 Also, to hold the intermediate results during the shortest-path
 calculation for each area, there is a separate routing table for each
 area holding the following entries:
 o  An entry for each router in the area. Routers are identified by
    their OSPF router ID. These routing table entries hold the set of
    shortest paths through a given area to a given router, which in
    turn allows calculation of paths to the IPv6 prefixes advertised
    by that router in Intra-area-prefix-LSAs. If the router is also an
    area-border router, these entries are also used to calculate paths
    for inter-area address prefixes. If in addition the router is the
    other endpoint of a virtual link, the routing table entry
    describes the cost and viability of the virtual link.
 o  An entry for each transit link in the area. Transit links have
    associated network-LSAs. Both the transit link and the network-LSA
    are identified by a combination of the Designated Router's
    Interface ID on the link and the Designated Router's OSPF Router
    ID. These routing table entries allow later calculation of paths
    to IP prefixes advertised for the transit link in intra-area-
    prefix-LSAs.
 The fields in the IPv4 OSPF routing table (see Section 11 of [Ref1])
 remain valid for IPv6: Optional capabilities (routers only), path
 type, cost, type 2 cost, link state origin, and for each of the equal
 cost paths to the destination, the next hop and advertising router.
 For IPv6, the link-state origin field in the routing table entry is
 the router-LSA or network-LSA that has directly or indirectly
 produced the routing table entry. For example, if the routing table
 entry describes a route to an IPv6 prefix, the link state origin is
 the router-LSA or network-LSA that is listed in the body of the
 intra-area-prefix-LSA that has produced the route (see Section
 A.4.9).

3.3.1. Routing table lookup

 Routing table lookup (i.e., determining the best matching routing
 table entry during IP forwarding) is the same for IPv6 as for IPv4.

3.4. Link State Advertisements

 For IPv6, the OSPF LSA header has changed slightly, with the LS type
 field expanding and the Options field being moved into the body of
 appropriate LSAs. Also, the formats of some LSAs have changed
 somewhat (namely router-LSAs, network-LSAs and AS-external-LSAs),
 while the names of other LSAs have been changed (type 3 and 4
 summary-LSAs are now inter-area-prefix-LSAs and inter-area-router-

Coltun, et al. Standards Track [Page 20] RFC 2740 OSPF for IPv6 December 1999

 LSAs respectively) and additional LSAs have been added (Link-LSAs and
 Intra-Area-Prefix-LSAs). Type of Service (TOS) has been removed from
 the OSPFv2 specification [Ref1], and is not encoded within OSPF for
 IPv6's LSAs.
 These changes will be described in detail in the following
 subsections.

3.4.1. The LSA Header

 In both IPv4 and IPv6, all OSPF LSAs begin with a standard 20 byte
 LSA header. However, the contents of this 20 byte header have changed
 in IPv6. The LS age, Advertising Router, LS Sequence Number, LS
 checksum and length fields within the LSA header remain unchanged, as
 documented in Sections 12.1.1, 12.1.5, 12.1.6, 12.1.7 and A.4.1 of
 [Ref1] respectively.  However, the following fields have changed for
 IPv6:
 Options
    The Options field has been removed from the standard 20 byte LSA
    header, and into the body of router-LSAs, network-LSAs, inter-
    area-router-LSAs and link-LSAs. The size of the Options field has
    increased from 8 to 24 bits, and some of the bit definitions have
    changed (see Section A.2). In addition a separate PrefixOptions
    field, 8 bits in length, is attached to each prefix advertised
    within the body of an LSA.
 LS type
    The size of the LS type field has increased from 8 to 16 bits,
    with the top two bits encoding flooding scope and the next bit
    encoding the handling of unknown LS types.  See Section A.4.2.1
    for the current coding of the LS type field.
 Link State ID
    Link State ID remains at 32 bits in length, but except for
    network-LSAs and link-LSAs, Link State ID has shed any addressing
    semantics. For example, an IPv6 router originating multiple AS-
    external-LSAs could start by assigning the first a Link State ID
    of 0.0.0.1, the second a Link State ID of 0.0.0.2, and so on.
    Instead of the IPv4 behavior of encoding the network number within
    the AS-external-LSA's Link State ID, the IPv6 Link State ID simply
    serves as a way to differentiate multiple LSAs originated by the
    same router.
    For network-LSAs, the Link State ID is set to the Designated
    Router's Interface ID on the link. When a router originates a
    Link-LSA for a given link, its Link State ID is set equal to the
    router's Interface ID on the link.

Coltun, et al. Standards Track [Page 21] RFC 2740 OSPF for IPv6 December 1999

3.4.2. The link-state database

 In IPv6, as in IPv4, individual LSAs are identified by a combination
 of their LS type, Link State ID and Advertising Router fields. Given
 two instances of an LSA, the most recent instance is determined by
 examining the LSAs' LS Sequence Number, using LS checksum and LS age
 as tiebreakers (see Section 13.1 of [Ref1]).
 In IPv6, the link-state database is split across three separate data
 structures. LSAs with AS flooding scope are contained within the
 top-level OSPF data structure (see Section 3.1) as long as either
 their LS type is known or their U-bit is 1 (flood even when
 unrecognized); this includes the AS-external-LSAs. LSAs with area
 flooding scope are contained within the appropriate area structure
 (see Section 3.1.1) as long as either their LS type is known or their
 U-bit is 1 (flood even when unrecognized); this includes router-LSAs,
 network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, and
 intra-area-prefix-LSAs. LSAs with unknown LS type and U-bit set to 0
 and/or link-local flooding scope are contained within the appropriate
 interface structure (see Section 3.1.2); this includes link-LSAs.
 To lookup or install an LSA in the database, you first examine the LS
 type and the LSA's context (i.e., to which area or link does the LSA
 belong). This information allows you to find the correct list of
 LSAs, all of the same LS type, where you then search based on the
 LSA's Link State ID and Advertising Router.

3.4.3. Originating LSAs

 The process of reoriginating an LSA in IPv6 is the same as in IPv4:
 the LSA's LS sequence number is incremented, its LS age is set to 0,
 its LS checksum is calculated, and the LSA is added to the link state
 database and flooded out the appropriate interfaces.
 To the list of events causing LSAs to be reoriginated, which for IPv4
 is given in Section 12.4 of [Ref1], the following events and/or
 actions are added for IPv6:
 o  The state of one of the router's interfaces changes. The router
    may need to (re)originate or flush its Link-LSA and one or more
    router-LSAs and/or intra-area-prefix-LSAs.
 o  The identity of a link's Designated Router changes. The router may
    need to (re)originate or flush the link's network-LSA and one or
    more router-LSAs and/or intra-area-prefix-LSAs.

Coltun, et al. Standards Track [Page 22] RFC 2740 OSPF for IPv6 December 1999

 o  A neighbor transitions to/from "Full" state.  The router may need
    to (re)originate or flush the link's network-LSA and one or more
    router-LSAs and/or intra-area-prefix-LSAs.
 o  The Interface ID of a neighbor changes. This may cause a new
    instance of a router-LSA to be originated for the associated area,
    and the reorigination of one or more intra-area-prefix-LSAs.
 o  A new prefix is added to an attached link, or a prefix is deleted
    (both through configuration). This causes the router to
    reoriginate its link-LSA for the link, or, if it is the only
    router attached to the link, causes the router to reoriginate an
    intra-area-prefix-LSA.
 o  A new link-LSA is received, causing the link's collection of
    prefixes to change. If the router is Designated Router for the
    link, it originates a new intra-area-prefix-LSA.
 Detailed construction of the seven required IPv6 LSA types is
 supplied by the following subsections. In order to display example
 LSAs, the network map in Figure 15 of [Ref1] has been reworked to
 show IPv6 addressing, resulting in Figure 1. The OSPF cost of each
 interface is has been displayed in Figure 1. The assignment of IPv6
 prefixes to network links is shown in Table 1. A single area address
 range has been configured for Area 1, so that outside of Area 1 all
 of its prefixes are covered by a single route to 5f00:0000:c001::/48.
 The OSPF interface IDs and the link-local addresses for the router
 interfaces in Figure 1 are given in Table 2.

Coltun, et al. Standards Track [Page 23] RFC 2740 OSPF for IPv6 December 1999

     ..........................................
     .                                  Area 1.
     .     +                                  .
     .     |                                  .
     .     | 3+---+1                          .
     .  N1 |--|RT1|-----+                     .
     .     |  +---+      \                    .
     .     |              \  ______           .
     .     +               \/       \      1+---+
     .                     *    N3   *------|RT4|------
     .     +               /\_______/       +---+
     .     |              /     |             .
     .     | 3+---+1     /      |             .
     .  N2 |--|RT2|-----+      1|             .
     .     |  +---+           +---+           .
     .     |                  |RT3|----------------
     .     +                  +---+           .
     .                          |2            .
     .                          |             .
     .                   +------------+       .
     .                          N4            .
     ..........................................
     Figure 1: Area 1 with IP addresses shown
            Network   IPv6 prefix
            -----------------------------------
            N1        5f00:0000:c001:0200::/56
            N2        5f00:0000:c001:0300::/56
            N3        5f00:0000:c001:0100::/56
            N4        5f00:0000:c001:0400::/56
     Table 1: IPv6 link prefixes for sample network
          Router   interface   Interface ID   link-local address
          -------------------------------------------------------
          RT1      to N1       1              fe80:0001::RT1
                   to N3       2              fe80:0002::RT1
          RT2      to N2       1              fe80:0001::RT2
                   to N3       2              fe80:0002::RT2
          RT3      to N3       1              fe80:0001::RT3
                   to N4       2              fe80:0002::RT3
          RT4      to N3       1              fe80:0001::RT4
     Table 2: OSPF Interface IDs and link-local addresses

Coltun, et al. Standards Track [Page 24] RFC 2740 OSPF for IPv6 December 1999

3.4.3.1. Router-LSAs

 The LS type of a router-LSA is set to the value 0x2001.  Router-LSAs
 have area flooding scope. A router may originate one or more router-
 LSAs for a given area. Each router-LSA contains an integral number of
 interface descriptions; taken together, the collection of router-LSAs
 originated by the router for an area describes the collected states
 of all the router's interfaces to the area. When multiple router-LSAs
 are used, they are distinguished by their Link State ID fields.
 The Options field in the router-LSA should be coded as follows. The
 V6-bit should be set. The E-bit should be clear if and only if the
 attached area is an OSPF stub area. The MC-bit should be set if and
 only if the router is running MOSPF (see [Ref8]). The N-bit should be
 set if and only if the attached area is an OSPF NSSA area.  The R-bit
 should be set. The DC-bit should be set if and only if the router can
 correctly process the DoNotAge bit when it appears in the LS age
 field of LSAs (see [Ref11]). All unrecognized bits in the Options
 field should be cleared
 To the left of the Options field, the router capability bits V, E and
 B should be coded according to Section 12.4.1 of [Ref1]. Bit W should
 be coded according to [Ref8].
 Each of the router's interfaces to the area are then described by
 appending "link descriptions" to the router-LSA. Each link
 description is 16 bytes long, consisting of 5 fields: (link) Type,
 Metric, Interface ID, Neighbor Interface ID and Neighbor Router ID
 (see Section A.4.3). Interfaces in state "Down" or "Loopback" are not
 described (although looped back interfaces can contribute prefixes to
 Intra-Area-Prefix-LSAs). Nor are interfaces without any full
 adjacencies described. All other interfaces to the area add zero, one
 or more link descriptions, the number and content of which depend on
 the interface type. Within each link description, the Metric field is
 always set the interface's output cost and the Interface ID field is
 set to the interface's OSPF Interface ID.
 Point-to-point interfaces
    If the neighboring router is fully adjacent, add a Type 1 link
    description (point-to-point). The Neighbor Interface ID field is
    set to the Interface ID advertised by the neighbor in its Hello
    packets, and the Neighbor Router ID field is set to the neighbor's
    Router ID.

Coltun, et al. Standards Track [Page 25] RFC 2740 OSPF for IPv6 December 1999

 Broadcast and NBMA interfaces
    If the router is fully adjacent to the link's Designated Router,
    or if the router itself is Designated Router and is fully adjacent
    to at least one other router, add a single Type 2 link description
    (transit network). The Neighbor Interface ID field is set to the
    Interface ID advertised by the Designated Router in its Hello
    packets, and the Neighbor Router ID field is set to the Designated
    Router's Router ID.
 Virtual links
    If the neighboring router is fully adjacent, add a Type 4 link
    description (virtual). The Neighbor Interface ID field is set to
    the Interface ID advertised by the neighbor in its Hello packets,
    and the Neighbor Router ID field is set to the neighbor's Router
    ID. Note that the output cost of a virtual link is calculated
    during the routing table calculation (see Section 3.7).
 Point-to-MultiPoint interfaces
    For each fully adjacent neighbor associated with the interface,
    add a separate Type 1 link description (point-to-point) with
    Neighbor Interface ID field set to the Interface ID advertised by
    the neighbor in its Hello packets, and Neighbor Router ID field
    set to the neighbor's Router ID.
 As an example, consider the router-LSA that router RT3 would
 originate for Area 1 in Figure 1. Only a single interface must be
 described, namely that which connects to the transit network N3. It
 assumes that RT4 has been elected Designated Router of Network N3.
   ; RT3's router-LSA for Area 1
   LS age = 0                     ;newly (re)originated
   LS type = 0x2001               ;router-LSA
   Link State ID = 0              ;first fragment
   Advertising Router = 192.1.1.3 ;RT3's Router ID
   bit E = 0                      ;not an AS boundary router
   bit B = 1                      ;area border router
   Options = (V6-bit|E-bit|R-bit)
       Type = 2                     ;connects to N3
       Metric = 1            ;cost to N3
       Interface ID = 1             ;RT3's Interface ID on N3
       Neighbor Interface ID = 1    ;RT4's Interface ID on N3
       Neighbor Router ID = 192.1.1.4 ; RT4's Router ID
 If for example another router was added to Network N4, RT3 would have
 to advertise a second link description for its connection to (the now
 transit) network N4. This could be accomplished by reoriginating the
 above router-LSA, this time with two link descriptions. Or, a

Coltun, et al. Standards Track [Page 26] RFC 2740 OSPF for IPv6 December 1999

 separate router-LSA could be originated with a separate Link State ID
 (e.g., using a Link State ID of 1) to describe the connection to N4.
 Host routes no longer appear in the router-LSA, but are instead
 included in intra-area-prefix-LSAs.

3.4.3.2. Network-LSAs

 The LS type of a network-LSA is set to the value 0x2002.  Network-
 LSAs have area flooding scope. A network-LSA is originated for every
 broadcast or NBMA link having two or more attached routers, by the
 link's Designated Router. The network-LSA lists all routers attached
 to the link.
 The procedure for originating network-LSAs in IPv6 is the same as the
 IPv4 procedure documented in Section 12.4.2 of [Ref1], with the
 following exceptions:
 o  An IPv6 network-LSA's Link State ID is set to the Interface ID of
    the Designated Router on the link.
 o  IPv6 network-LSAs do not contain a Network Mask. All addressing
    information formerly contained in the IPv4 network-LSA has now
    been consigned to intra-Area-Prefix-LSAs.
 o  The Options field in the network-LSA is set to the logical OR of
    the Options fields contained within the link's associated link-
    LSAs.  In this way, the network link exhibits a capability when at
    least one of the link's routers requests that the capability be
    asserted.
 As an example, assuming that Router RT4 has been elected Designated
 Router of Network N3 in Figure 1, the following network-LSA is
 originated:
   ; Network-LSA for Network N3
   LS age = 0                     ;newly (re)originated
   LS type = 0x2002               ;network-LSA
   Link State ID = 1              ;RT4's Interface ID on N3
   Advertising Router = 192.1.1.4 ;RT4's Router ID
   Options = (V6-bit|E-bit|R-bit)
          Attached Router = 192.1.1.4    ;Router ID
          Attached Router = 192.1.1.1    ;Router ID
          Attached Router = 192.1.1.2    ;Router ID
          Attached Router = 192.1.1.3    ;Router ID

Coltun, et al. Standards Track [Page 27] RFC 2740 OSPF for IPv6 December 1999

3.4.3.3. Inter-Area-Prefix-LSAs

 The LS type of an inter-area-prefix-LSA is set to the value 0x2003.
 Inter-area-prefix-LSAs have area flooding scope. In IPv4, inter-
 area-prefix-LSAs were called type 3 summary-LSAs. Each inter-area-
 prefix-LSA describes a prefix external to the area, yet internal to
 the Autonomous System.
 The procedure for originating inter-area-prefix-LSAs in IPv6 is the
 same as the IPv4 procedure documented in Sections 12.4.3 and 12.4.3.1
 of [Ref1], with the following exceptions:
 o  The Link State ID of an inter-area-prefix-LSA has lost all of its
    addressing semantics, and instead simply serves to distinguish
    multiple inter-area-prefix-LSAs that are originated by the same
    router.
 o  The prefix is described by the PrefixLength, PrefixOptions and
    Address Prefix fields embedded within the LSA body. Network Mask
    is no longer specified.
 o  The NU-bit in the PrefixOptions field should be clear. The coding
    of the MC-bit depends upon whether, and if so how, MOSPF is
    operating in the routing domain (see [Ref8]).
 o  Link-local addresses must never be advertised in inter-area-
    prefix-LSAs.
    As an example, the following shows the inter-area-prefix-LSA that
    Router RT4 originates into the OSPF backbone area, condensing all
    of Area 1's prefixes into the single prefix 5f00:0000:c001::/48.
    The cost is set to 4, which is the maximum cost to all of the
    prefix' individual components. The prefix is padded out to an even
    number of 32-bit words, so that it consumes 64-bits of space
    instead of 48 bits.
      ; Inter-area-prefix-LSA for Area 1 addresses
      ; originated by Router RT4 into the backbone
      LS age = 0                  ;newly (re)originated
      LS type = 0x2003            ;inter-area-prefix-LSA
      Advertising Router = 192.1.1.4       ;RT4's ID
      Metric = 4                  ;maximum to components
      PrefixLength = 48
      PrefixOptions = 0
      Address Prefix = 5f00:0000:c001 ;padded to 64-bits

Coltun, et al. Standards Track [Page 28] RFC 2740 OSPF for IPv6 December 1999

3.4.3.4. Inter-Area-Router-LSAs

    The LS type of an inter-area-router-LSA is set to the value
    0x2004. Inter-area-router-LSAs have area flooding scope. In IPv4,
    inter-area-router-LSAs were called type 4 summary-LSAs. Each
    inter-area-router-LSA describes a path to a destination OSPF
    router (an ASBR) that is external to the area, yet internal to the
    Autonomous System.
    The procedure for originating inter-area-router-LSAs in IPv6 is
    the same as the IPv4 procedure documented in Section 12.4.3 of
    [Ref1], with the following exceptions:
 o  The Link State ID of an inter-area-router-LSA is no longer the
    destination router's OSPF Router ID, but instead simply serves to
    distinguish multiple inter-area-router-LSAs that are originated by
    the same router. The destination router's Router ID is now found
    in the body of the LSA.
 o  The Options field in an inter-area-router-LSA should be set equal
    to the Options field contained in the destination router's own
    router-LSA. The Options field thus describes the capabilities
    supported by the destination router.
 As an example, consider the OSPF Autonomous System depicted in Figure
 6 of [Ref1]. Router RT4 would originate into Area 1 the following
 inter-area-router-LSA for destination router RT7.
   ; inter-area-router-LSA for AS boundary router RT7
   ; originated by Router RT4 into Area 1
   LS age = 0                  ;newly (re)originated
   LS type = 0x2004            ;inter-area-router-LSA
   Advertising Router = 192.1.1.4  ;RT4's ID
   Options = (V6-bit|E-bit|R-bit)  ;RT7's capabilities
   Metric = 14                     ;cost to RT7
   Destination Router ID = Router RT7's ID

3.4.3.5. AS-external-LSAs

 The LS type of an AS-external-LSA is set to the value 0x4005. AS-
 external-LSAs have AS flooding scope. Each AS-external-LSA describes
 a path to a prefix external to the Autonomous System.
 The procedure for originating AS-external-LSAs in IPv6 is the same as
 the IPv4 procedure documented in Section 12.4.4 of [Ref1], with the
 following exceptions:

Coltun, et al. Standards Track [Page 29] RFC 2740 OSPF for IPv6 December 1999

 o  The Link State ID of an AS-external-LSA has lost all of its
    addressing semantics, and instead simply serves to distinguish
    multiple AS-external-LSAs that are originated by the same router.
 o  The prefix is described by the PrefixLength, PrefixOptions and
    Address Prefix fields embedded within the LSA body. Network Mask
    is no longer specified.
 o  The NU-bit in the PrefixOptions field should be clear. The coding
    of the MC-bit depends upon whether, and if so how, MOSPF is
    operating in the routing domain (see [Ref8]).
 o  Link-local addresses can never be advertised in AS-external-LSAs.
 o  The forwarding address is present in the AS-external-LSA if and
    only if the AS-external-LSA's bit F is set.
 o  The external route tag is present in the AS-external-LSA if and
    only if the AS-external-LSA's bit T is set.
 o  The capability for an AS-external-LSA to reference another LSA has
    been included, by inclusion of the Referenced LS Type field and
    the optional Referenced Link State ID field (the latter present if
    and only if Referenced LS Type is non-zero). This capability is
    for future use; for now Referenced LS Type should be set to 0 and
    received non-zero values for this field should be ignored.
 As an example, consider the OSPF Autonomous System depicted in Figure
 6 of [Ref1]. Assume that RT7 has learned its route to N12 via BGP,
 and that it wishes to advertise a Type 2 metric into the AS.  Further
 assume the the IPv6 prefix for N12 is the value 5f00:0000:0a00::/40.
 RT7 would then originate the following AS-external-LSA for the
 external network N12.  Note that within the AS-external-LSA, N12's
 prefix occupies 64 bits of space, to maintain 32-bit alignment.
   ; AS-external-LSA for Network N12,
   ; originated by Router RT7
   LS age = 0                  ;newly (re)originated
   LS type = 0x4005            ;AS-external-LSA
   Link State ID = 123         ;or something else
   Advertising Router = Router RT7's ID
   bit E = 1                   ;Type 2 metric
   bit F = 0                   ;no forwarding address
   bit T = 1                   ;external route tag included
   Metric = 2
   PrefixLength = 40
   PrefixOptions = 0

Coltun, et al. Standards Track [Page 30] RFC 2740 OSPF for IPv6 December 1999

   Referenced LS Type = 0      ;no Referenced Link State ID
   Address Prefix = 5f00:0000:0a00 ;padded to 64-bits
   External Route Tag = as per BGP/OSPF interaction

3.4.3.6. Link-LSAs

 The LS type of a Link-LSA is set to the value 0x0008.  Link-LSAs have
 link-local flooding scope. A router originates a separate Link-LSA
 for each attached link that supports 2 or more (including the
 originating router itself) routers.
 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 in the Network-LSA that will be originated
 for the link.
 A Link-LSA for a given Link L is built in the following fashion:
 o  The Link State ID is set to the router's Interface ID on Link L.
 o  The Router Priority of the router's interface to Link L is
    inserted into the Link-LSA.
 o  The Link-LSA's Options field is set to those bits that the router
    wishes set in Link L's Network LSA.
 o  The router inserts its link-local address on Link L into the
    Link-LSA. This information will be used when the other routers on
    Link L do their next hop calculations (see Section 3.8.1.1).
 o  Each IPv6 address prefix that has been configured into the router
    for Link L is added to the Link-LSA, by specifying values for
    PrefixLength, PrefixOptions, and Address Prefix fields.
 After building a Link-LSA for a given link, the router installs the
 link-LSA into the associate interface data structure and floods the
 Link-LSA onto the link. All other routers on the link will receive
 the Link-LSA, but it will go no further.
 As an example, consider the Link-LSA that RT3 will build for N3 in
 Figure 1. Suppose that the prefix 5f00:0000:c001:0100::/56 has been
 configured within RT3 for N3. This will give rise to the following
 Link-LSA, which RT3 will flood onto N3, but nowhere else. Note that
 not all routers on N3 need be configured with the prefix; those not
 configured will learn the prefix when receiving RT3's Link-LSA.

Coltun, et al. Standards Track [Page 31] RFC 2740 OSPF for IPv6 December 1999

   ; RT3's Link-LSA for N3
   LS age = 0                  ;newly (re)originated
   LS type = 0x0008            ;Link-LSA
   Link State ID = 1           ;RT3's Interface ID on N3
   Advertising Router = 192.1.1.3 ;RT3's Router ID
   Rtr Pri = 1                 ;RT3's N3 Router Priority
   Options = (V6-bit|E-bit|R-bit)
   Link-local Interface Address = fe80:0001::RT3
   # prefixes = 1
   PrefixLength = 56
   PrefixOptions = 0
   Address Prefix = 5f00:0000:c001:0100 ;pad to 64-bits

3.4.3.7. Intra-Area-Prefix-LSAs

 The LS type of an intra-area-prefix-LSA is set to the value 0x2009.
 Intra-area-prefix-LSAs have area flooding scope. An intra-area-
 prefix-LSA has one of two functions. It associates a list of IPv6
 address prefixes with a transit network link by referencing a
 network- LSA, or associates a list of IPv6 address prefixes with a
 router by referencing a router-LSA. A stub link's prefixes are
 associated with its attached router.
 A router may originate multiple intra-area-prefix-LSAs for a given
 area, distinguished by their Link State ID fields. Each intra-area-
 prefix-LSA contains an integral number of prefix descriptions.
 A link's Designated Router originates one or more intra-area-prefix-
 LSAs to advertise the link's prefixes throughout the area. For a link
 L, L's Designated Router builds an intra-area-prefix-LSA in the
 following fashion:
 o  In order to indicate that the prefixes are to be associated with
    the Link L, the fields Referenced LS type, Referenced Link State
    ID, and Referenced
    Advertising Router are set to the corresponding fields in Link L's
    network-LSA (namely LS type, Link State ID, and Advertising Router
    respectively). This means that Referenced LS Type is set to
    0x2002, Referenced Link State ID is set to the Designated Router's
    Interface ID on Link L, and Referenced Advertising Router is set
    to the Designated Router's Router ID.
 o  Each Link-LSA associated with Link L is examined (these are in the
    Designated Router's interface structure for Link L). If the Link-
    LSA's Advertising Router is fully adjacent to the Designated
    Router, the list of prefixes in the Link-LSA is copied into the

Coltun, et al. Standards Track [Page 32] RFC 2740 OSPF for IPv6 December 1999

    intra-area-prefix-LSA that is being built.  Prefixes having the
    NU-bit and/or LA-bit set in their Options field should not be
    copied, nor should link-local addresses be copied.  Each prefix is
    described by the PrefixLength, PrefixOptions, and Address Prefix
    fields. Multiple prefixes having the same PrefixLength and Address
    Prefix are considered to be duplicates; in this case their Prefix
    Options fields should be merged by logically OR'ing the fields
    together, and a single resulting prefix should be copied into the
    intra-area-prefix-LSA. The Metric field for all prefixes is set to
    0.
 o  The "# prefixes" field is set to the number of prefixes that the
    router has copied into the LSA. If necessary, the list of prefixes
    can be spread across multiple intra-area-prefix-LSAs in order to
    keep the LSA size small.
    A router builds an intra-area-prefix-LSA to advertise its own
    prefixes, and those of its attached stub links.  A Router RTX
    would build its intra-area-prefix-LSA in the following fashion:
 o  In order to indicate that the prefixes are to be associated with
    the Router RTX itself, RTX sets Referenced LS type to 0x2001,
    Referenced Link State ID to 0, and Referenced Advertising Router
    to RTX's own Router ID.
 o  Router RTX examines its list of interfaces to the area. If the
    interface is in state Down, its prefixes are not included. If the
    interface has been reported in RTX's router-LSA as a Type 2 link
    description (link to transit network), its prefixes are not
    included (they will be included in the intra-area-prefix-LSA for
    the link instead). If the interface type is Point-to-MultiPoint,
    or the interface is in state Loopback, or the interface connects
    to a point-to-point link which has not been assigned a prefix,
    then the site-local and global scope IPv6 addresses associated
    with the interface (if any) are copied into the intra-area-
    prefix-LSA, setting the LA-bit in the PrefixOptions field, and
    setting the PrefixLength to 128 and the Metric to 0.  Otherwise,
    the list of site-local and global prefixes configured in RTX for
    the link are copied into the intra-area-prefix-LSA by specifying
    the PrefixLength, PrefixOptions, and Address Prefix fields. The
    Metric field for each of these prefixes is set to the interface's
    output cost.
 o  RTX adds the IPv6 prefixes for any directly attached hosts
    belonging to the area (see Section C.7) to the intra-area-prefix-
    LSA.

Coltun, et al. Standards Track [Page 33] RFC 2740 OSPF for IPv6 December 1999

 o  If RTX has one or more virtual links configured through the area,
    it includes one of its site-local or global scope IPv6 interface
    addresses in the LSA (if it hasn't already), setting the LA-bit in
    the PrefixOptions field, and setting the PrefixLength to 128 and
    the Metric to 0. This information will be used later in the
    routing calculation so that the two ends of the virtual link can
    discover each other's IPv6 addresses.
 o  The "# prefixes" field is set to the number of prefixes that the
    router has copied into the LSA. If necessary, the list of prefixes
    can be spread across multiple intra-area-prefix-LSAs in order to
    keep the LSA size small.
 For example, the intra-area-prefix-LSA originated by RT4 for Network
 N3 (assuming that RT4 is N3's Designated Router), and the intra-
 area-prefix-LSA originated into Area 1 by Router RT3 for its own
 prefixes, are pictured below.
   ; Intra-area-prefix-LSA
   ; for network link N3
   LS age = 0                  ;newly (re)originated
   LS type = 0x2009            ;Intra-area-prefix-LSA
   Link State ID = 5           ;or something
   Advertising Router = 192.1.1.4 ;RT4's Router ID
   # prefixes = 1
   Referenced LS type = 0x2002 ;network-LSA reference
   Referenced Link State ID = 1
   Referenced Advertising Router = 192.1.1.4
   PrefixLength = 56           ;N3's prefix
   PrefixOptions = 0
   Metric = 0
   Address Prefix = 5f00:0000:c001:0100 ;pad
   ; RT3's Intra-area-prefix-LSA
   ; for its own prefixes
   LS age = 0                  ;newly (re)originated
   LS type = 0x2009            ;Intra-area-prefix-LSA
   Link State ID = 177         ;or something
   Advertising Router = 192.1.1.3 ;RT3's Router ID
   # prefixes = 1
   Referenced LS type = 0x2001 ;router-LSA reference
   Referenced Link State ID = 0
   Referenced Advertising Router = 192.1.1.3
   PrefixLength = 56           ;N4's prefix

Coltun, et al. Standards Track [Page 34] RFC 2740 OSPF for IPv6 December 1999

   PrefixOptions = 0
   Metric = 2                  ;N4 interface cost
   Address Prefix = 5f00:0000:c001:0400 ;pad
 When network conditions change, it may be necessary for a router to
 move prefixes from one intra-area-prefix-LSA to another. For example,
 if the router is Designated Router for a link but the link has no
 other attached routers, the link's prefixes are advertised in an
 intra-area-prefix-LSA referring to the Designated Router's router-
 LSA.  When additional routers appear on the link, a network-LSA is
 originated for the link and the link's prefixes are moved to an
 intra-area-prefix-LSA referring to the network-LSA.
 Note that in the intra-area-prefix-LSA, the "Referenced Advertising
 Router" is always equal to the router that is originating the intra-
 area-prefix-LSA (i.e., the LSA's Advertising Router). The reason that
 the Referenced Advertising Router field appears is that, even though
 it is currently redundant, it may not be in the future. We may
 sometime want to use the same LSA format to advertise address
 prefixes for other protocol suites. In that event, the Designated
 Router may not be running the other protocol suite, and so another of
 the link's routers may need to send out the prefix-LSA. In that case,
 "Referenced Advertising Router" and "Advertising Router" would be
 different.

3.5. Flooding

 Most of the flooding algorithm remains unchanged from the IPv4
 flooding mechanisms described in Section 13 of [Ref1]. In particular,
 the processes for determining which LSA instance is newer (Section
 13.1 of [Ref1]), responding to updates of self-originated LSAs
 (Section 13.4 of [Ref1]), sending Link State Acknowledgment packets
 (Section 13.5 of [Ref1]), retransmitting LSAs (Section 13.6 of
 [Ref1]) and receiving Link State Acknowledgment packets (Section 13.7
 of [Ref1]) are exactly the same for IPv6 and IPv4.
 However, the addition of flooding scope and handling options for
 unrecognized LSA types (see Section A.4.2.1) has caused some changes
 in the OSPF flooding algorithm: the reception of Link State Updates
 (Section 13 in [Ref1]) and the sending of Link State Updates (Section
 13.3 of [Ref1]) must take into account the LSA's scope and U-bit
 setting. Also, installation of LSAs into the OSPF database (Section
 13.2 of [Ref1]) causes different events in IPv6, due to the
 reorganization of LSA types and contents in IPv6. These changes are
 described in detail below.

Coltun, et al. Standards Track [Page 35] RFC 2740 OSPF for IPv6 December 1999

3.5.1. Receiving Link State Update packets

 The encoding of flooding scope in the LS type and the need to process
 unknown LS types causes modifications to the processing of received
 Link State Update packets. As in IPv4, each LSA in a received Link
 State Update packet is examined. In IPv4, eight steps are executed
 for each LSA, as described in Section 13 of [Ref1]. For IPv6, all the
 steps are the same, except that Steps 2 and 3 are modified as
 follows:
 (2)   Examine the LSA's LS type.  If the LS type is
       unknown, the area has been configured as a stub area,
       and either the LSA's flooding scope is set to "AS
       flooding scope" or the U-bit of the LS type is set to
       1 (flood even when unrecognized), then discard the
       LSA and get the next one from the Link State Update
       Packet. This generalizes the IPv4 behavior where AS-
       external-LSAs are not flooded into/throughout stub
       areas.
 (3)   Else if the flooding scope of the LSA is set to
       "reserved", discard the LSA and get the next one from
       the Link State Update Packet.
 Steps 5b (sending Link State Update packets) and 5d (installing LSAs
 in the link state database) in Section 13 of [Ref1] are also somewhat
 different for IPv6, as described in Sections 3.5.2 and 3.5.3 below.

3.5.2. Sending Link State Update packets

 The sending of Link State Update packets is described in Section 13.3
 of [Ref1]. For IPv4 and IPv6, the steps for sending a Link State
 Update packet are the same (steps 1 through 5 of Section 13.3 in
 [Ref1]). However, the list of eligible interfaces out which to flood
 the LSA is different.  For IPv6, the eligible interfaces are selected
 based on the following factors:
 o  The LSA's flooding scope.
 o  For LSAs with area or link-local flooding scoping, the particular
    area or interface that the LSA is associated with.
 o  Whether the LSA has a recognized LS type.
 o  The setting of the U-bit in the LS type. If the U-bit is set to 0,
    unrecognized LS types are treated as having link-local scope. If
    set to 1, unrecognized LS types are stored and flooded as if they
    were recognized.

Coltun, et al. Standards Track [Page 36] RFC 2740 OSPF for IPv6 December 1999

 Choosing the set of eligible interfaces then breaks into the
 following cases:
 Case 1
    The LSA's LS type is recognized. In this case, the set of eligible
    interfaces is set depending on the flooding scope encoded in the
    LS type. If the flooding scope is "AS flooding scope", the
    eligible interfaces are all router interfaces excepting virtual
    links. In addition, AS-external-LSAs are not flooded out
    interfaces connecting to stub areas. If the flooding scope is
    "area flooding scope", the set of eligible interfaces are those
    interfaces connecting to the LSA's associated area. If the
    flooding scope is "link-local flooding scope", then there is a
    single eligible interface, the one connecting to the LSA's
    associated link (which, when the LSA is received in a Link State
    Update packet, is also the interface the LSA was received on).
 Case 2
    The LS type is unrecognized, and the U-bit in the LS Type is set
    to 0 (treat the LSA as if it had link-local flooding scope). In
    this case there is a single eligible interface, namely, the
    interface on which the LSA was received.
 Case 3
    The LS type is unrecognized, and the U-bit in the LS Type is set
    to 1 (store and flood the LSA, as if type understood). In this
    case, select the eligible interfaces based on the encoded flooding
    scope as in Case 1 above. However, in this case interfaces
    attached to stub areas are always excluded.
 A further decision must sometimes be made before adding an LSA to a
 given neighbor's link-state retransmission list (Step 1d in Section
 13.3 of [Ref1]). If the LS type is recognized by the router, but not
 by the neighbor (as can be determined by examining the Options field
 that the neighbor advertised in its Database Description packet) and
 the LSA's U-bit is set to 0, then the LSA should be added to the
 neighbor's link-state retransmission list if and only if that
 neighbor is the Designated Router or Backup Designated Router for the
 attached link. The LS types described in detail by this memo, namely
 router-LSAs (LS type 0x2001), network-LSAs (0x2002), Inter-Area-
 Prefix-LSAs (0x2003), Inter-Area-Router-LSAs (0x2004), AS-External-
 LSAs (0x4005), Link-LSAs (0x0008) and Intra-Area-Prefix-LSAs (0x2009)
 are assumed to be understood by all routers. However, as an example
 the group-membership-LSA (0x2006) is understood only by MOSPF routers
 and since it has its U-bit set to 0, it should only be forwarded to a
 non-MOSPF neighbor (determined by examining the MC-bit in the
 neighbor's Database Description packets' Options field) when the
 neighbor is Designated Router or Backup Designated Router for the

Coltun, et al. Standards Track [Page 37] RFC 2740 OSPF for IPv6 December 1999

 attached link.
 The previous paragraph solves a problem in IPv4 OSPF extensions such
 as MOSPF, which require that the Designated Router support the
 extension in order to have the new LSA types flooded across broadcast
 and NBMA networks (see Section 10.2 of [Ref8]).

3.5.3. Installing LSAs in the database

 There are three separate places to store LSAs, depending on their
 flooding scope. LSAs with AS flooding scope are stored in the global
 OSPF data structure (see Section 3.1) as long as their LS type is
 known or their U-bit is 1. LSAs with area flooding scope are stored
 in the appropriate area data structure (see Section 3.1.1) as long as
 their LS type is known or their U-bit is 1. LSAs with link-local
 flooding scope, and those LSAs with unknown LS type and U-bit set to
 0 (treat the LSA as if it had link-local flooding scope) are stored
 in the appropriate interface structure.
 When storing the LSA into the link-state database, a check must be
 made to see whether the LSA's contents have changed.  Changes in
 contents are indicated exactly as in Section 13.2 of [Ref1]. When an
 LSA's contents have been changed, the following parts of the routing
 table must be recalculated, based on the LSA's LS type:
 Router-LSAs, Network-LSAs, Intra-Area-Prefix-LSAs and Link-LSAs
    The entire routing table is recalculated, starting with the
    shortest path calculation for each area (see Section 3.8).
 Inter-Area-Prefix-LSAs and Inter-Area-Router-LSAs
    The best route to the destination described by the LSA must be
    recalculated (see Section 16.5 in [Ref1]).  If this destination is
    an AS boundary router, it may also be necessary to re-examine all
    the AS-external-LSAs.
 AS-external-LSAs
    The best route to the destination described by the AS-external-LSA
    must be recalculated (see Section 16.6 in [Ref1]).
 As in IPv4, any old instance of the LSA must be removed from the
 database when the new LSA is installed.  This old instance must also
 be removed from all neighbors' Link state retransmission lists.

Coltun, et al. Standards Track [Page 38] RFC 2740 OSPF for IPv6 December 1999

3.6. Definition of self-originated LSAs

 In IPv6 the definition of a self-originated LSA has been simplified
 from the IPv4 definition appearing in Sections 13.4 and 14.1 of
 [Ref1]. For IPv6, self-originated LSAs are those LSAs whose
 Advertising Router is equal to the router's own Router ID.

3.7. Virtual links

 OSPF virtual links for IPv4 are described in Section 15 of [Ref1].
 Virtual links are the same in IPv6, with the following exceptions:
 o  LSAs having AS flooding scope are never flooded over virtual
    adjacencies, nor are LSAs with AS flooding scope summarized over
    virtual adjacencies during the Database Exchange process. This is
    a generalization of the IPv4 treatment of AS-external-LSAs.
 o  The IPv6 interface address of a virtual link must be an IPv6
    address having site-local or global scope, instead of the link-
    local addresses used by other interface types. This address is
    used as the IPv6 source for OSPF protocol packets sent over the
    virtual link.
 o  Likewise, the virtual neighbor's IPv6 address is an IPv6 address
    with site-local or global scope. To enable the discovery of a
    virtual neighbor's IPv6 address during the routing calculation,
    the neighbor advertises its virtual link's IPv6 interface address
    in an Intra-Area-Prefix-LSA originated for the virtual link's
    transit area (see Sections 3.4.3.7 and 3.8.1).
 o  Like all other IPv6 OSPF interfaces, virtual links are assigned
    unique (within the router) Interface IDs. These are advertised in
    Hellos sent over the virtual link, and in the router's router-
    LSAs.

3.8. Routing table calculation

 The IPv6 OSPF routing calculation proceeds along the same lines as
 the IPv4 OSPF routing calculation, following the five steps specified
 by Section 16 of [Ref1]. High level differences between the IPv6 and
 IPv4 calculations include:
 o  Prefix information has been removed from router-LSAs, and now is
    advertised in intra-area-prefix-LSAs. Whenever [Ref1] specifies
    that stub networks within router-LSAs be examined, IPv6 will
    instead examine prefixes within intra-area-prefix-LSAs.

Coltun, et al. Standards Track [Page 39] RFC 2740 OSPF for IPv6 December 1999

 o  Type 3 and 4 summary-LSAs have been renamed inter-area-prefix-LSAs
    and inter-area-router-LSAs (respectively).
 o  Addressing information is no longer encoded in Link State IDs, and
    must instead be found within the body of LSAs.
 o  In IPv6, a router can originate multiple router-LSAs within a
    single area, distinguished by Link State ID. These router-LSAs
    must be treated as a single aggregate by the area's shortest path
    calculation (see Section 3.8.1).
 For each area, routing table entries have been created for the area's
 routers and transit links, in order to store the results of the
 area's shortest-path tree calculation (see Section 3.8.1). These
 entries are then used when processing intra-area-prefix-LSAs, inter-
 area-prefix-LSAs and inter-area-router-LSAs, as described in Section
 3.8.2.
 Events generated as a result of routing table changes (Section 16.7
 of [Ref1]), and the equal-cost multipath logic (Section 16.8 of
 [Ref1]) are identical for both IPv4 and IPv6.

3.8.1. Calculating the shortest path tree for an area

 The IPv4 shortest path calculation is contained in Section 16.1 of
 [Ref1].  The graph used by the shortest-path tree calculation is
 identical for both IPv4 and IPv6. The graph's vertices are routers
 and transit links, represented by router-LSAs and network-LSAs
 respectively. A router is identified by its OSPF Router ID, while a
 transit link is identified by its Designated Router's Interface ID
 and OSPF Router ID. Both routers and transit links have associated
 routing table entries within the area (see Section 3.3).
 Section 16.1 of [Ref1] splits up the shortest path calculations into
 two stages. First the Dijkstra calculation is performed, and then the
 stub links are added onto the tree as leaves. The IPv6 calculation
 maintains this split.
 The Dijkstra calculation for IPv6 is identical to that specified for
 IPv4, with the following exceptions (referencing the steps from the
 Dijkstra calculation as described in Section 16.1 of [Ref1]):
 o  The Vertex ID for a router is the OSPF Router ID. The Vertex ID
    for a transit network is a combination of the Interface ID and
    OSPF Router ID of the network's Designated Router.

Coltun, et al. Standards Track [Page 40] RFC 2740 OSPF for IPv6 December 1999

 o  In Step 2, when a router Vertex V has just been added to the
    shortest path tree, there may be multiple LSAs associated with the
    router. All Router-LSAs with Advertising Router set to V's OSPF
    Router ID must processed as an aggregate, treating them as
    fragments of a single large router-LSA. The Options field and the
    router type bits (bits W, V, E and B) should always be taken from
    "fragment" with the smallest Link State ID.
 o  Step 2a is not needed in IPv6, as there are no longer stub network
    links in router-LSAs.
 o  In Step 2b, if W is a router, there may again be multiple LSAs
    associated with the router. All Router-LSAs with Advertising
    Router set to W's OSPF Router ID must processed as an aggregate,
    treating them as fragments of a single large router-LSA.
 o  In Step 4, there are now per-area routing table entries for each
    of an area's routers, instead of just the area border routers.
    These entries subsume all the functionality of IPv4's area border
    router routing table entries, including the maintenance of virtual
    links.  When the router added to the area routing table in this
    step is the other end of a virtual link, the virtual neighbor's IP
    address is set as follows: The collection of intra-area-prefix-
    LSAs originated by the virtual neighbor is examined, with the
    virtual neighbor's IP address being set to the first prefix
    encountered having the "LA-bit" set.
 o  Routing table entries for transit networks, which are no longer
    associated with IP networks, are also modified in Step 4.
 The next stage of the shortest path calculation proceeds similarly to
 the two steps of the second stage of Section 16.1 in [Ref1]. However,
 instead of examining the stub links within router-LSAs, the list of
 the area's intra-area-prefix-LSAs is examined. A prefix advertisement
 whose "NU-bit" is set should not be included in the routing
 calculation. The cost of any advertised prefix is the sum of the
 prefix' advertised metric plus the cost to the transit vertex (either
 router or transit network) identified by intra-area-prefix-LSA's
 Referenced LS type, Referenced Link State ID and Referenced
 Advertising Router fields. This latter cost is stored in the transit
 vertex' routing table entry for the area.

3.8.1.1. The next hop calculation

 In IPv6, the calculation of the next hop's IPv6 address (which will
 be a link-local address) proceeds along the same lines as the IPv4
 next hop calculation (see Section 16.1.1 of [Ref1]). The only
 difference is in calculating the next hop IPv6 address for a router

Coltun, et al. Standards Track [Page 41] RFC 2740 OSPF for IPv6 December 1999

 (call it Router X) which shares a link with the calculating router.
 In this case the calculating router assigns the next hop IPv6 address
 to be the link-local interface address contained in Router X's Link-
 LSA (see Section A.4.8) for the link. This procedure is necessary
 since on some links, such as NBMA links, the two routers need not be
 neighbors, and therefore might not be exchanging OSPF Hellos.

3.8.2. Calculating the inter-area routes

 Calculation of inter-area routes for IPv6 proceeds along the same
 lines as the IPv4 calculation in Section 16.2 of [Ref1], with the
 following modifications:
 o  The names of the Type 3 summary-LSAs and Type 4 summary-LSAs have
    been changed to inter-area-prefix-LSAs and inter-area-router-LSAs
    respectively.
 o  The Link State ID of the above LSA types no longer encodes the
    network or router described by the LSA.  Instead, an address
    prefix is contained in the body of an inter-area-prefix-LSA, and a
    described router's OSPF Router ID is carried in the body of an
    inter-area- router-LSA.
 o  Prefixes having the "NU-bit" set in their Prefix Options field
    should be ignored by the inter-area route calculation.
 When a single inter-area-prefix-LSA or inter-area-router-LSA has
 changed, the incremental calculations outlined in Section 16.5 of
 [Ref1] can be performed instead of recalculating the entire routing
 table.

3.8.3. Examining transit areas' summary-LSAs

 Examination of transit areas' summary-LSAs in IPv6 proceeds along the
 same lines as the IPv4 calculation in Section 16.3 of [Ref1],
 modified in the same way as the IPv6 inter-area route calculation in
 Section 3.8.2.

3.8.4. Calculating AS external routes

 The IPv6 AS external route calculation proceeds along the same lines
 as the IPv4 calculation in Section 16.4 of [Ref1], with the following
 exceptions:
 o  The Link State ID of the AS-external-LSA types no longer encodes
    the network described by the LSA. Instead, an address prefix is
    contained in the body of an AS- external-LSA.

Coltun, et al. Standards Track [Page 42] RFC 2740 OSPF for IPv6 December 1999

 o  The default route is described by AS-external-LSAs which advertise
    zero length prefixes.
 o  Instead of comparing the AS-external-LSA's Forwarding address
    field to 0.0.0.0 to see whether a forwarding address has been
    used, bit F of the external-LSA is examined. A forwarding address
    is in use if and only if bit F is set.
 o  Prefixes having the "NU-bit" set in their Prefix Options field
    should be ignored by the inter-area route calculation.
 When a single AS-external-LSA has changed, the incremental
 calculations outlined in Section 16.6 of [Ref1] can be performed
 instead of recalculating the entire routing table.

3.9. Multiple interfaces to a single link

 In OSPF for IPv6, a router may have multiple interfaces to a single
 link. All interfaces are involved in the reception and transmission
 of data traffic, however only a single interface sends and receives
 OSPF control traffic. In more detail:
 o  Each of the multiple interfaces are assigned different Interface
    IDs.  In this way the router can automatically detect when
    multiple interfaces attach to the same link, when receiving Hellos
    from its own Router ID but with an Interface ID other than the
    receiving interface's.
 o  The router turns off the sending and receiving of OSPF packets
    (that is, control traffic) on all but one of the interfaces to the
    link. The choice of interface to send and receive control traffic
    is implementation dependent; as one example, the interface with
    the highest Interface ID could be chosen.  If the router is
    elected DR, it will be this interface's Interface ID that will be
    used as the network-LSA's Link State ID.
 o  All the multiple interfaces to the link will however appear in the
    router-LSA. In addition, a Link-LSA will be generated for each of
    the multiple interfaces. In this way, all interfaces will be
    included in OSPF's routing calculations.
 o  If the interface which is responsible for sending and receiving
    control traffic fails,  another will have to take over, reforming
    all neighbor adjacencies from scratch. This failure can be
    detected by the router itself, when the other interfaces to the
    same link cease to hear the router's own Hellos.

Coltun, et al. Standards Track [Page 43] RFC 2740 OSPF for IPv6 December 1999

References

 [Ref1]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
 [Ref2]  McKenzie, A., "ISO Transport Protocol specification ISO DP
         8073", RFC 905, April 1984.
 [Ref3]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB
         using SMIv2", RFC 2233, November 1997.
 [Ref4]  Fuller, V., Li, T, Yu, J. and K. Varadhan, "Classless Inter-
         Domain Routing (CIDR): an Address Assignment and Aggregation
         Strategy", RFC 1519, September 1993.
 [Ref5]  Varadhan, K., Hares, S. and Y. Rekhter, "BGP4/IDRP for IP---
         OSPF Interaction", RFC 1745, December 1994
 [Ref6]  Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
         1700, 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, March
         1994.
 [Ref9]  Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587,
         March 1994.
 [Ref10] Ferguson, D., "The OSPF External Attributes LSA",
         unpublished.
 [Ref11] Moy, J., "Extending OSPF to Support Demand Circuits", RFC
         1793, April 1995.
 [Ref12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
         November 1990.
 [Ref13] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
         RFC 1771, March 1995.
 [Ref14] Deering, S. and R. Hinden, "Internet Protocol, Version 6
         (IPv6) Specification", RFC 2460, December 1998.
 [Ref15] Hinden, R. and S. Deering, "IP Version 6 Addressing
         Architecture", RFC 2373, July 1998.

Coltun, et al. Standards Track [Page 44] RFC 2740 OSPF for IPv6 December 1999

 [Ref16] Conta, A. and S. Deering, "Internet Control Message Protocol
         (ICMPv6) for the Internet Protocol Version 6 (IPv6)
         Specification" RFC 2463, December 1998.
 [Ref17] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
         for IP Version 6 (IPv6)", RFC 2461, December 1998.
 [Ref18] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for
         IP version 6", RFC 1981, August 1996.
 [Ref19] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
         2402, November 1998.
 [Ref20] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
         (ESP)", RFC 2406, November 1998.

Coltun, et al. Standards Track [Page 45] RFC 2740 OSPF for IPv6 December 1999

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 1280 bytes
 unless Path MTU Discovery is being performed [Ref14].
 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.

Coltun, et al. Standards Track [Page 46] RFC 2740 OSPF for IPv6 December 1999

 AllSPFRouters
    This multicast address has been assigned the value FF02::5.  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 encapsulating IPv6 header.

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.
 An option mismatch between routers can cause a variety of behaviors,
 depending on the particular option. Some option mismatches prevent
 neighbor relationships from forming (e.g., the E-bit below); these
 mismatches are discovered through the sending and receiving of Hello
 packets. Some option mismatches prevent particular LSA types from
 being flooded across adjacencies (e.g., the MC-bit below); these are
 discovered through the sending and receiving of Database Description
 packets. Some option mismatches prevent routers from being included
 in one or more of the various routing calculations because of their
 reduced functionality (again the MC-bit is an example); these
 mismatches are discovered by examining LSAs.
 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.

Coltun, et al. Standards Track [Page 47] RFC 2740 OSPF for IPv6 December 1999

                           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
   If this bit is clear, the router/link should be excluded from IPv6
   routing calculations. See Section 3.8 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].
 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 cannot 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.
 DC-bit
   This bit describes the router's handling of demand circuits, as
   specified in [Ref10].

A.3 OSPF Packet Formats

 There are five distinct OSPF packet types.  All OSPF packet types
 begin with a standard 16 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.

Coltun, et al. Standards Track [Page 48] RFC 2740 OSPF for IPv6 December 1999

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

A.3.1 The OSPF packet header

 Every OSPF packet starts with a standard 16 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 3.2.2 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.
 Router ID
     The Router ID of the packet's source.

Coltun, et al. Standards Track [Page 49] RFC 2740 OSPF for IPv6 December 1999

 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
     OSPF uses the standard checksum calculation for IPv6
     applications: The 16-bit one's complement of the one's complement
     sum of the entire contents of the packet, starting with the OSPF
     packet header, and prepending a "pseudo-header" of IPv6 header
     fields, as specified in [Ref14, section 8.1]. The "Upper-Layer
     Packet Length" in the pseudo-header is set to value of the OSPF
     packet header's length field.  The Next Header value used in the
     pseudo-header is 89. 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. Before computing the checksum, the checksum
     field in the OSPF packet header is set to 0.
 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.

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).

Coltun, et al. Standards Track [Page 50] RFC 2740 OSPF for IPv6 December 1999

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      3               |       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
     implementations it may be possible to use the MIB-II IfIndex
     ([Ref3]).
 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.

Coltun, et al. Standards Track [Page 51] RFC 2740 OSPF for IPv6 December 1999

 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.

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.

Coltun, et al. Standards Track [Page 52] RFC 2740 OSPF for IPv6 December 1999

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      3        |       2       |        Packet length          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                           Router ID                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                             Area ID                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           Checksum            |  Instance ID  |      0        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       0       |               Options                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Interface MTU         |       0        |0|0|0|0|0|I|M|MS
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    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].
 Options
    The optional capabilities supported by the router, as documented
    in Section A.2.
 Interface MTU
    The size in bytes of the largest IPv6 datagram that can be sent
    out the    associated interface, without fragmentation.  The MTUs
    of common Internet link  types can be found in Table 7-1    of
    [Ref12]. Interface MTU should be set to 0 in Database Description
    packets sent over virtual links.

Coltun, et al. Standards Track [Page 53] RFC 2740 OSPF for IPv6 December 1999

 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.
 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.

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].

Coltun, et al. Standards Track [Page 54] RFC 2740 OSPF for IPv6 December 1999

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      3           |       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).

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 3.5.

Coltun, et al. Standards Track [Page 55] RFC 2740 OSPF for IPv6 December 1999

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      3        |       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.

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. 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].
 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 (see Section 13.5 of [Ref1] for
 details).
 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.

Coltun, et al. Standards Track [Page 56] RFC 2740 OSPF for IPv6 December 1999

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      3              |       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 current
 instance.

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 3.5
 for more information concerning the flooding algorithm).  This
 collection of LSAs is called the link-state database.

Coltun, et al. Standards Track [Page 57] RFC 2740 OSPF for IPv6 December 1999

 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 3.8.

A.4.1 IPv6 Prefix Representation

 IPv6 addresses are bit strings of length 128. IPv6 routing
 algorithms, and OSPF for IPv6 in particular, advertise IPv6 address
 prefixes. IPv6 address prefixes are bit strings whose length ranges
 between 0 and 128 bits (inclusive).
 Within OSPF, IPv6 address prefixes are always represented by a
 combination of three fields: PrefixLength, PrefixOptions, and Address
 Prefix. PrefixLength is the length in bits of the prefix.
 PrefixOptions is an 8-bit field describing various capabilities
 associated with the prefix (see Section A.4.2). Address Prefix is an
 encoding of the prefix itself as an even multiple of 32-bit words,
 padding with zero bits as necessary; this encoding consumes
 (PrefixLength + 31) / 32) 32-bit words.
 The default route is represented by a prefix of length 0.
 Examples of IPv6 Prefix representation in OSPF can be found in
 Sections A.4.5, A.4.7, A.4.8 and A.4.9.

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.

Coltun, et al. Standards Track [Page 58] RFC 2740 OSPF for IPv6 December 1999

 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.

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 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. See Section A.4.2.1 for a
    detailed description of LS type.

Coltun, et al. Standards Track [Page 59] RFC 2740 OSPF for IPv6 December 1999

 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.
 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.

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:
         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 the LSA's function code.  Its values are:
   U-bit   LSA Handling
   -------------------------------------------------------------
   0       Treat the LSA as if it had link-local flooding scope
   1       Store and flood the LSA, as if type understood

Coltun, et al. Standards Track [Page 60] RFC 2740 OSPF for IPv6 December 1999

 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.
       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

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 3.4.3.1. Router-LSAs are
 flooded throughout a single area only.

Coltun, et al. Standards Track [Page 61] RFC 2740 OSPF for IPv6 December 1999

  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  |W|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
 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).

Coltun, et al. Standards Track [Page 62] RFC 2740 OSPF for IPv6 December 1999

 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).
 bit W
    When set, the router is a wild-card multicast receiver.  When
    running MOSPF, these routers receive all multicast datagrams,
    regardless of destination. See Sections 3, 4 and A.2 of [Ref8] for
    details.
 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
 Metric
    The cost of using this router interface, for outbound traffic.
 Interface ID
    The Interface ID assigned to the interface being described. See
    Sections 3.1.2 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 attached link.
 Neighbor Router ID
    The Router ID the neighbor router (or the attached link's
    Designated Router, for Type 2 interfaces).

Coltun, et al. Standards Track [Page 63] RFC 2740 OSPF for IPv6 December 1999

    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.

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
 3.4.3.2.
  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. Standards Track [Page 64] RFC 2740 OSPF for IPv6 December 1999

A.4.5 Inter-Area-Prefix-LSAs

 Inter-Area-Prefix-LSAs have LS type equal to 0x2003.  These LSAs are
 are the IPv6 equivalent of OSPF for IPv4's type 3 summary-LSAs (see
 Section 12.4.3 of [Ref1]).  Originated by area border routers, they
 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 3.4.3.3.
 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. Standards Track [Page 65] RFC 2740 OSPF for IPv6 December 1999

A.4.6 Inter-Area-Router-LSAs

 Inter-Area-Router-LSAs have LS type equal to 0x2004.  These LSAs are
 are the IPv6 equivalent of OSPF for IPv4's type 4 summary-LSAs (see
 Section 12.4.3 of [Ref1]).  Originated by area border routers, they
 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 3.4.3.4.
  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. Standards Track [Page 66] RFC 2740 OSPF for IPv6 December 1999

A.4.7 AS-external-LSAs

 AS-external-LSAs have LS type equal to 0x4005.  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 3.4.3.5.
 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|1|0|          5               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Link State ID                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Advertising Router                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    LS sequence number                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        LS checksum           |             length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        |E|F|T|                 Metric                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | PrefixLength  | PrefixOptions |     Referenced LS Type        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Address Prefix                         |
 |                             ...                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +-                                                             -+
 |                                                               |
 +-                Forwarding Address (Optional)                -+
 |                                                               |
 +-                                                             -+
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           External Route Tag (Optional)                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               Referenced Link State ID (Optional)             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Coltun, et al. Standards Track [Page 67] RFC 2740 OSPF for IPv6 December 1999

 bit E
    The type of external metric.  If bit E is set, the metric
    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.
 bit T
    If set, an External Route Tag 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 will be forwarded to this address. Must not
    be set to the IPv6 Unspecified Address (0:0:0:0:0:0:0:0).
 External Route Tag
    A 32-bit field which may be used to communicate additional
    information between AS boundary routers; see [Ref5] for example
    usage. Included in the LSA if and only if bit T has been set.
 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.

Coltun, et al. Standards Track [Page 68] RFC 2740 OSPF for IPv6 December 1999

 All, none or some of the fields labeled Forwarding address, External
 Route Tag and Referenced Link State ID may be present in the AS-
 external-LSA (as indicated by the setting of bit F, bit T and
 Referenced LS type respectively). However, when present Forwarding
 Address always comes first, with External Route Tag always preceding
 Referenced Link State ID.

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.

Coltun, et al. Standards Track [Page 69] RFC 2740 OSPF for IPv6 December 1999

  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)               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        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.

Coltun, et al. Standards Track [Page 70] RFC 2740 OSPF for IPv6 December 1999

 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.

A.4.9 Intra-Area-Prefix-LSAs

 Intra-Area-Prefix-LSAs have LS type equal to 0x2009. A router uses
 Intra-Area-Prefix-LSAs to advertise one or more IPv6 address
 prefixes that are associated with a) the router itself, b) an
 attached stub network segment or c) an attached transit network
 segment. In IPv4, a) and b) were accomplished via the router's
 router-LSA, and c) via a network-LSA. However, in OSPF for IPv6 all
 addressing information has been removed from router-LSAs and
 network-LSAs, leading to the introduction of the Intra-Area-Prefix-LSA.
 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.

Coltun, et al. Standards Track [Page 71] RFC 2740 OSPF for IPv6 December 1999

  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.
    Router
 Referenced LS type, Referenced Link State ID and Referenced
    Advertising
    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.

Coltun, et al. Standards Track [Page 72] RFC 2740 OSPF for IPv6 December 1999

 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.

B. Architectural Constants

 Architectural constants for the OSPF protocol are defined in Appendix
 B 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

Coltun, et al. Standards Track [Page 73] RFC 2740 OSPF for IPv6 December 1999

    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.
    Because the size of the Router ID is smaller than an IPv6 address,
    it cannot be set to one of the router's IPv6 addresses (as is
    commonly done for IPv4). Possible Router ID assignment procedures
    for IPv6 include: a) assign the IPv6 Router ID as one of the
    router's IPv4 addresses or b) assign IPv6 Router IDs through some
    local administrative procedure (similar to procedures used by
    manufacturers to assign product serial numbers).
    The Router ID of 0.0.0.0 is reserved, and should not be used.

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 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.

Coltun, et al. Standards Track [Page 74] RFC 2740 OSPF for IPv6 December 1999

 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 12.4.3.1 of
    [Ref1] 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 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
    ([Ref3]).
 IPv6 prefixes
    The list of IPv6 prefixes to associate with the link. These will
    be advertised in intra-area-prefix-LSAs.

Coltun, et al. Standards Track [Page 75] RFC 2740 OSPF for IPv6 December 1999

 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 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

Coltun, et al. Standards Track [Page 76] RFC 2740 OSPF for IPv6 December 1999

    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 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:

Coltun, et al. Standards Track [Page 77] RFC 2740 OSPF for IPv6 December 1999

 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.

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 prefixes are advertised in intra-area-prefix-LSAs.  They
 indicate either internal router addresses, 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 prefix
    The IPv6 prefix belonging to 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's prefix belongs.

Coltun, et al. Standards Track [Page 78] RFC 2740 OSPF for IPv6 December 1999

Security Considerations

 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.
 Most OSPF implementations will be running on systems that support
 multiple protocols, many of them having independent security
 assumptions and domains.  When IPSEC is used to protect OSPF packets,
 it is important for the implementation to check the IPSEC SA, and
 local SA database to make sure that the packet originates from a
 source THAT IS TRUSTED FOR OSPF PURPOSES.

Authors' Addresses

 Rob Coltun
 Siara Systems
 300 Ferguson Drive
 Mountain View, CA 94043
 Phone: (650) 390-9030
 EMail: rcoltun@siara.com
 Dennis Ferguson
 Juniper Networks
 385 Ravendale Drive
 Mountain View, CA  94043
 Phone: +1 650 526 8004
 EMail: dennis@juniper.com
 John Moy
 Sycamore Networks, Inc.
 10 Elizabeth Drive
 Chelmsford, MA 01824
 Phone: (978) 367-2161
 Fax:   (978) 250-3350
 EMail: jmoy@sycamorenet.com

Coltun, et al. Standards Track [Page 79] RFC 2740 OSPF for IPv6 December 1999

Full Copyright Statement

 Copyright (C) The Internet Society (1999).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Coltun, et al. Standards Track [Page 80]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2740.txt · Last modified: 1999/12/09 23:10 (external edit)