GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5340

Network Working Group R. Coltun Request for Comments: 5340 Acoustra Productions Obsoletes: 2740 D. Ferguson Category: Standards Track Juniper Networks

                                                                J. Moy
                                                Sycamore Networks, Inc
                                                        A. Lindem, Ed.
                                                      Redback Networks
                                                             July 2008
                           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.

Abstract

 This document describes the modifications to OSPF to support version
 6 of the Internet Protocol (IPv6).  The fundamental mechanisms of
 OSPF (flooding, Designated Router (DR) election, area support, Short
 Path First (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.  These modifications will necessitate
 incrementing the protocol version from version 2 to version 3.  OSPF
 for IPv6 is also referred to as OSPF version 3 (OSPFv3).
 Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as
 described herein include the following.  Addressing semantics have
 been removed from OSPF packets and the basic Link State
 Advertisements (LSAs).  New LSAs have been created to carry IPv6
 addresses and prefixes.  OSPF now runs on a per-link basis rather
 than on a per-IP-subnet basis.  Flooding scope for LSAs has been
 generalized.  Authentication has been removed from the OSPF protocol
 and instead relies on IPv6's Authentication Header and Encapsulating
 Security Payload (ESP).
 Even with larger IPv6 addresses, most packets in OSPF for IPv6 are
 almost as compact as those in OSPF for IPv4.  Most fields and 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 5340 OSPF for IPv6 July 2008

 All of OSPF for IPv4's optional capabilities, including demand
 circuit support and Not-So-Stubby Areas (NSSAs), are also supported
 in OSPF for IPv6.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  4
   1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
 2.  Differences from OSPF for IPv4 . . . . . . . . . . . . . . . .  5
   2.1.  Protocol Processing Per-Link, Not Per-Subnet . . . . . . .  5
   2.2.  Removal of Addressing Semantics  . . . . . . . . . . . . .  5
   2.3.  Addition of Flooding Scope . . . . . . . . . . . . . . . .  6
   2.4.  Explicit Support for Multiple Instances per Link . . . . .  6
   2.5.  Use of Link-Local Addresses  . . . . . . . . . . . . . . .  7
   2.6.  Authentication Changes . . . . . . . . . . . . . . . . . .  7
   2.7.  Packet Format Changes  . . . . . . . . . . . . . . . . . .  8
   2.8.  LSA Format Changes . . . . . . . . . . . . . . . . . . . .  9
   2.9.  Handling Unknown LSA Types . . . . . . . . . . . . . . . . 10
   2.10. Stub/NSSA Area Support . . . . . . . . . . . . . . . . . . 11
   2.11. Identifying Neighbors by Router ID . . . . . . . . . . . . 11
 3.  Differences with RFC 2740  . . . . . . . . . . . . . . . . . . 11
   3.1.  Support for Multiple Interfaces on the Same Link . . . . . 11
   3.2.  Deprecation of MOSPF for IPv6  . . . . . . . . . . . . . . 12
   3.3.  NSSA Specification . . . . . . . . . . . . . . . . . . . . 12
   3.4.  Stub Area Unknown LSA Flooding Restriction Deprecated  . . 12
   3.5.  Link LSA Suppression . . . . . . . . . . . . . . . . . . . 12
   3.6.  LSA Options and Prefix Options Updates . . . . . . . . . . 13
   3.7.  IPv6 Site-Local Addresses  . . . . . . . . . . . . . . . . 13
 4.  Implementation Details . . . . . . . . . . . . . . . . . . . . 13
   4.1.  Protocol Data Structures . . . . . . . . . . . . . . . . . 14
     4.1.1.  The Area Data Structure  . . . . . . . . . . . . . . . 15
     4.1.2.  The Interface Data Structure . . . . . . . . . . . . . 15
     4.1.3.  The Neighbor Data Structure  . . . . . . . . . . . . . 16
   4.2.  Protocol Packet Processing . . . . . . . . . . . . . . . . 17
     4.2.1.  Sending Protocol Packets . . . . . . . . . . . . . . . 17
       4.2.1.1.  Sending Hello Packets  . . . . . . . . . . . . . . 18
       4.2.1.2.  Sending Database Description Packets . . . . . . . 19
     4.2.2.  Receiving Protocol Packets . . . . . . . . . . . . . . 19
       4.2.2.1.  Receiving Hello Packets  . . . . . . . . . . . . . 21
   4.3.  The Routing table Structure  . . . . . . . . . . . . . . . 22
     4.3.1.  Routing Table Lookup . . . . . . . . . . . . . . . . . 23
   4.4.  Link State Advertisements  . . . . . . . . . . . . . . . . 23
     4.4.1.  The LSA Header . . . . . . . . . . . . . . . . . . . . 23
     4.4.2.  The Link-State Database  . . . . . . . . . . . . . . . 24
     4.4.3.  Originating LSAs . . . . . . . . . . . . . . . . . . . 25
       4.4.3.1.  LSA Options  . . . . . . . . . . . . . . . . . . . 27
       4.4.3.2.  Router-LSAs  . . . . . . . . . . . . . . . . . . . 27

Coltun, et al. Standards Track [Page 2] RFC 5340 OSPF for IPv6 July 2008

       4.4.3.3.  Network-LSAs . . . . . . . . . . . . . . . . . . . 29
       4.4.3.4.  Inter-Area-Prefix-LSAs . . . . . . . . . . . . . . 30
       4.4.3.5.  Inter-Area-Router-LSAs . . . . . . . . . . . . . . 31
       4.4.3.6.  AS-External-LSAs . . . . . . . . . . . . . . . . . 32
       4.4.3.7.  NSSA-LSAs  . . . . . . . . . . . . . . . . . . . . 33
       4.4.3.8.  Link-LSAs  . . . . . . . . . . . . . . . . . . . . 34
       4.4.3.9.  Intra-Area-Prefix-LSAs . . . . . . . . . . . . . . 36
     4.4.4.  Future LSA Validation  . . . . . . . . . . . . . . . . 40
   4.5.  Flooding . . . . . . . . . . . . . . . . . . . . . . . . . 40
     4.5.1.  Receiving Link State Update Packets  . . . . . . . . . 40
     4.5.2.  Sending Link State Update Packets  . . . . . . . . . . 41
     4.5.3.  Installing LSAs in the Database  . . . . . . . . . . . 43
   4.6.  Definition of Self-Originated LSAs . . . . . . . . . . . . 43
   4.7.  Virtual Links  . . . . . . . . . . . . . . . . . . . . . . 44
   4.8.  Routing Table Calculation  . . . . . . . . . . . . . . . . 44
     4.8.1.  Calculating the Shortest-Path Tree for an Area . . . . 45
     4.8.2.  The Next-Hop Calculation . . . . . . . . . . . . . . . 44
     4.8.3.  Calculating the Inter-Area Routes  . . . . . . . . . . 47
     4.8.4.  Examining Transit Areas' Summary-LSAs  . . . . . . . . 48
     4.8.5.  Calculating AS External and NSSA Routes  . . . . . . . 48
   4.9.  Multiple Interfaces to a Single Link . . . . . . . . . . . 48
     4.9.1.  Standby Interface State  . . . . . . . . . . . . . . . 50
 5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 52
 6.  Manageability Considerations . . . . . . . . . . . . . . . . . 52
 7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 52
   7.1.  MOSPF for OSPFv3 Deprecation IANA Considerations . . . . . 53
 8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 53
 9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
   9.1.  Normative References . . . . . . . . . . . . . . . . . . . 55
   9.2.  Informative References . . . . . . . . . . . . . . . . . . 56
 Appendix A.  OSPF Data Formats . . . . . . . . . . . . . . . . . . 57
   A.1.  Encapsulation of OSPF Packets  . . . . . . . . . . . . . . 57
   A.2.  The Options Field  . . . . . . . . . . . . . . . . . . . . 58
   A.3.  OSPF Packet Formats  . . . . . . . . . . . . . . . . . . . 60
     A.3.1.  The OSPF Packet Header . . . . . . . . . . . . . . . . 60
     A.3.2.  The Hello Packet . . . . . . . . . . . . . . . . . . . 62
     A.3.3.  The Database Description Packet  . . . . . . . . . . . 63
     A.3.4.  The Link State Request Packet  . . . . . . . . . . . . 65
     A.3.5.  The Link State Update Packet . . . . . . . . . . . . . 66
     A.3.6.  The Link State Acknowledgment Packet . . . . . . . . . 67
   A.4.  LSA Formats  . . . . . . . . . . . . . . . . . . . . . . . 68
     A.4.1.  IPv6 Prefix Representation . . . . . . . . . . . . . . 69
       A.4.1.1.  Prefix Options . . . . . . . . . . . . . . . . . . 69
     A.4.2.  The LSA Header . . . . . . . . . . . . . . . . . . . . 70
       A.4.2.1.  LSA Type . . . . . . . . . . . . . . . . . . . . . 72
     A.4.3.  Router-LSAs  . . . . . . . . . . . . . . . . . . . . . 73
     A.4.4.  Network-LSAs . . . . . . . . . . . . . . . . . . . . . 76
     A.4.5.  Inter-Area-Prefix-LSAs . . . . . . . . . . . . . . . . 77

Coltun, et al. Standards Track [Page 3] RFC 5340 OSPF for IPv6 July 2008

     A.4.6.  Inter-Area-Router-LSAs . . . . . . . . . . . . . . . . 78
     A.4.7.  AS-External-LSAs . . . . . . . . . . . . . . . . . . . 79
     A.4.8.  NSSA-LSAs  . . . . . . . . . . . . . . . . . . . . . . 82
     A.4.9.  Link-LSAs  . . . . . . . . . . . . . . . . . . . . . . 82
     A.4.10. Intra-Area-Prefix-LSAs . . . . . . . . . . . . . . . . 84
 Appendix B.  Architectural Constants . . . . . . . . . . . . . . . 86
 Appendix C.  Configurable Constants  . . . . . . . . . . . . . . . 86
   C.1.  Global Parameters  . . . . . . . . . . . . . . . . . . . . 86
   C.2.  Area Parameters  . . . . . . . . . . . . . . . . . . . . . 87
   C.3.  Router Interface Parameters  . . . . . . . . . . . . . . . 88
   C.4.  Virtual Link Parameters  . . . . . . . . . . . . . . . . . 90
   C.5.  NBMA Network Parameters  . . . . . . . . . . . . . . . . . 91
   C.6.  Point-to-Multipoint Network Parameters . . . . . . . . . . 92
   C.7.  Host Route Parameters  . . . . . . . . . . . . . . . . . . 92

1. Introduction

 This document describes the modifications to OSPF to support version
 6 of the Internet Protocol (IPv6).  The fundamental mechanisms of
 OSPF (flooding, Designated Router (DR) election, area support,
 (Shortest Path First) 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.  These modifications will necessitate
 incrementing the protocol version from version 2 to version 3.  OSPF
 for IPv6 is also referred to as OSPF version 3 (OSPFv3).
 This document is organized as follows.  Section 2 describes the
 differences between OSPF for IPv4 (OSPF version 2) and OSPF for IPv6
 (OSPF version 3) in detail.  Section 3 describes the difference
 between RFC 2740 and this document.  Section 4 provides
 implementation details for the changes.  Appendix A gives the OSPF
 for IPv6 packet and Link State Advertisement (LSA) formats.  Appendix
 B lists the OSPF architectural constants.  Appendix C describes
 configuration parameters.

1.1. Requirements Notation

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [RFC-KEYWORDS].

1.2. Terminology

 This document attempts to use terms from both the OSPF for IPv4
 specification ([OSPFV2]) and the IPv6 protocol specifications
 ([IPV6]).  This has produced a mixed result.  Most of the terms used
 both by OSPF and IPv6 have roughly the same meaning (e.g.,

Coltun, et al. Standards Track [Page 4] RFC 5340 OSPF for IPv6 July 2008

 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.
 In the context of this document, an OSPF instance is a separate
 protocol instance complete with its own protocol data structures
 (e.g., areas, interfaces, neighbors), link-state database, protocol
 state machines, and protocol processing (e.g., SPF calculation).

2. Differences from OSPF for IPv4

 Most of the algorithms from OSPF for IPv4 [OSPFV2] have been
 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 [OSPFV2].

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" ([IPV6]).
 "Interfaces" connect to links.  Multiple IPv6 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 IPv6 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 ([OSPFV2]) should generally be replaced
 by link.  Likewise, an OSPF interface now connects to a link instead
 of an IP subnet.
 This change affects the receiving of OSPF protocol packets, the
 contents of Hello packets, and the contents of 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:

Coltun, et al. Standards Track [Page 5] RFC 5340 OSPF for IPv6 July 2008

 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.
    Previously, they had been identified by an IPv4 address on
    broadcast, NBMA (Non-Broadcast Multi-Access), and point-to-
    multipoint links.

2.3. Addition of Flooding Scope

 Flooding scope for LSAs has been generalized and is now explicitly
 coded in the LSA's LS type field.  There are now three separate
 flooding scopes for LSAs:
 o  Link-local scope.  LSA is only flooded on the local link and no
    further.  Used for the new link-LSA.  See Section 4.4.3.8 for
    details.
 o  Area scope.  LSA is only flooded throughout a single OSPF area.
    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.  A router that originates AS scoped LSAs is
    considered an AS Boundary Router (ASBR) and will set its E-bit in
    router-LSAs for regular areas.

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 supporting
 separate OSPF routing domains that wish 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.

Coltun, et al. Standards Track [Page 6] RFC 5340 OSPF for IPv6 July 2008

 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 data structures.  Instance ID solely affects the reception
 of OSPF packets and applies to normal OSPF interfaces and virtual
 links.

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 [IP6ADDR].
 Link-local unicast addresses are assigned from the IPv6 address range
 FE80/10.
 OSPF for IPv6 assumes that each router has been assigned link-local
 unicast addresses on each of the router's attached physical links
 [IP6ADDR].  On all OSPF interfaces except virtual links, OSPF packets
 are sent using the interface's associated link-local unicast address
 as the source address.  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, a global scope IPv6 address MUST be used as the
 source address for OSPF protocol packets.
 Link-local addresses appear in OSPF link-LSAs (see Section 4.4.3.8).
 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 4.4.3.4), AS-external-LSAs
 (Section 4.4.3.6), NSSA-LSAs (Section 4.4.3.7), or intra-area-prefix-
 LSAs (Section 4.4.3.9).

2.6. Authentication Changes

 In OSPF for IPv6, authentication has been removed from the OSPF
 protocol.  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 data structures.
 When running over IPv6, OSPF relies on the IP Authentication Header
 (see [IPAUTH]) and the IP Encapsulating Security Payload (see
 [IPESP]) as described in [OSPFV3-AUTH] to ensure integrity and
 authentication/confidentiality of routing exchanges.

Coltun, et al. Standards Track [Page 7] RFC 5340 OSPF for IPv6 July 2008

 Protection of OSPF packet exchanges against accidental data
 corruption is provided by the standard IPv6 Upper-Layer checksum (as
 described in Section 8.1 of [IPV6]), covering the entire OSPF packet
 and prepended IPv6 pseudo-header (see Appendix 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 incremented from 2 to 3.
 o  The Options field in Hello packets and Database Description
    packets has been expanded to 24 bits.
 o  The Authentication and AuType fields have been removed from the
    OSPF packet header (see Section 2.6).
 o  The Hello packet now contains no address information at all.
    Rather, it now includes an Interface ID that the originating
    router has assigned to uniquely identify (among its own
    interfaces) its interface to the link.  This Interface ID will be
    used as the network-LSA's Link State ID if the router becomes the
    Designated Router on the link.
 o  Two Options bits, the "R-bit" and the "V6-bit", have been added to
    the Options field for processing router-LSAs during the SPF
    calculation (see Appendix 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 datagrams
    belonging to another protocol family may be forwarded.
 o  The OSPF packet header now includes an "Instance ID" that allows
    multiple OSPF protocol instances to be run on a single link (see
    Section 2.4).

Coltun, et al. Standards Track [Page 8] RFC 5340 OSPF for IPv6 July 2008

2.8. LSA Format Changes

 All addressing semantics have been removed from the LSA header,
 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 Appendix 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 Appendix A.4.1).  The default
    route is expressed as a prefix with length 0.
 o  Router-LSAs and network-LSAs now have no address information and
    are network protocol independent.
 o  Router interface information MAY be spread across multiple router-
    LSAs.  Receivers MUST concatenate all the router-LSAs originated
    by a given router when running the SPF calculation.
 o  A new LSA called the link-LSA has been introduced.  Link-LSAs have
    link-local flooding scope; they are never flooded beyond the link
    with which they are associated.  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 advertise a collection of Options bits to
    associate with the network-LSA that will be originated for the
    link.  See Section 4.4.3.8 for details.
 o  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 [OSPFV2]), 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

Coltun, et al. Standards Track [Page 9] RFC 5340 OSPF for IPv6 July 2008

    in all cases.  On NBMA links, next-hop routers do not necessarily
    exchange Hellos.  Rather, these routers learn of each other's
    existence by way of the Designated Router (DR).
 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, NSSA-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 4.4.3.9 for
    details.
 o  Inclusion of a forwarding address or external route tag in AS-
    external-LSAs is now optional.  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.  For
    example, this reference could be used to attach BGP path
    attributes to external routes.

2.9. Handling Unknown LSA Types

 Handling of unknown LSA types has been made more flexible so that,
 based on the LS type, unknown LSA types are either treated as having
 link-local flooding scope, or are stored and flooded as if they were
 understood.  This behavior is explicitly coded in the LSA Handling
 bit of the link state header's LS type field (see the U-bit in
 Appendix A.4.2.1).

Coltun, et al. Standards Track [Page 10] RFC 5340 OSPF for IPv6 July 2008

 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/NSSA Area Support

 In OSPF for IPv4, stub and NSSA 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 and NSSA 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.  NSSA areas are restricted to these types and, of
 course, NSSA-LSAs.  This is the IPv6 equivalent of the LSA types
 carried in IPv4 stub areas: router-LSAs, network-LSAs, type 3
 summary-LSAs and for NSSA areas: stub area types and NSSA-LSAs.

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 while 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
 [OSPFV2]), the lookup of neighbors (Section 10 of [OSPFV2]), and the
 reception of Hello packets (Section 10.5 of [OSPFV2]).
 The Router ID of 0.0.0.0 is reserved and SHOULD NOT be used.

3. Differences with RFC 2740

 OSPFv3 implementations based on RFC 2740 will fully interoperate with
 implementations based on this specification.  There are, however,
 some protocol additions and changes (all of which are backward
 compatible).

3.1. Support for Multiple Interfaces on the Same Link

 This protocol feature was only partially specified in the RFC 2740.
 The level of specification was insufficient to implement the feature.
 Section 4.9 specifies the additions and clarifications necessary for
 implementation.  They are fully compatible with RFC 2740.

Coltun, et al. Standards Track [Page 11] RFC 5340 OSPF for IPv6 July 2008

3.2. Deprecation of MOSPF for IPv6

 This protocol feature was only partially specified in RFC 2740.  The
 level of specification was insufficient to implement the feature.
 There are no known implementations.  Multicast Extensions to OSPF
 (MOSPF) support and its attendant protocol fields have been
 deprecated from OSPFv3.  Refer to Section 4.4.3.2, Section 4.4.3.4,
 Section 4.4.3.6, Section 4.4.3.7, Appendix A.2, Appendix A.4.2.1,
 Appendix A.4.3, Appendix A.4.1.1, and Section 7.1.

3.3. NSSA Specification

 This protocol feature was only partially specified in RFC 2740.  The
 level of specification was insufficient to implement the function.
 This document includes an NSSA specification unique to OSPFv3.  This
 specification coupled with [NSSA] provide sufficient specification
 for implementation.  Refer to Section 4.8.5, Appendix A.4.3,
 Appendix A.4.8, and [NSSA].

3.4. Stub Area Unknown LSA Flooding Restriction Deprecated

 In RFC 2740 [OSPFV3], flooding of unknown LSA was restricted within
 stub and NSSA areas.  The text describing this restriction is
 included below.
      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 Appendix 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 can
      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.
 This restriction has been deprecated.  OSPFv3 routers will flood link
 and area scope LSAs whose LS type is unrecognized and whose U-bit is
 set to 1 throughout stub and NSSA areas.  There are no backward-
 compatibility issues other than OSPFv3 routers still supporting the
 restriction may not propagate newly defined LSA types.

3.5. Link LSA Suppression

 The LinkLSASuppression interface configuration parameter has been
 added.  If LinkLSASuppression is configured for an interface and the
 interface type is not broadcast or NBMA, origination of the link-LSA

Coltun, et al. Standards Track [Page 12] RFC 5340 OSPF for IPv6 July 2008

 may be suppressed.  The LinkLSASuppression interface configuration
 parameter is described in Appendix C.3.  Section 4.8.2 and
 Section 4.4.3.8 were updated to reflect the parameter's usage.

3.6. LSA Options and Prefix Options Updates

 The LSA Options and Prefix Options fields have been updated to
 reflect recent protocol additions.  Specifically, bits related to
 MOSPF have been deprecated, Options field bits common with OSPFv2
 have been reserved, and the DN-bit has been added to the prefix-
 options.  Refer to Appendix A.2 and Appendix A.4.1.1.

3.7. IPv6 Site-Local Addresses

 All references to IPv6 site-local addresses have been removed.

4. Implementation Details

 When going from IPv4 to IPv6, the basic OSPF mechanisms remain
 unchanged from those documented in [OSPFV2].  These mechanisms are
 briefly outlined in Section 4 of [OSPFV2].  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, which includes 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, as well as to elect Designated Routers and
 Backup Designated Routers on broadcast and NBMA links.  The decision
 as to which neighbor relationships become adjacencies, and 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
 [OSPFV2] remains completely unchanged for IPv6:
 o  Both IPv4 and IPv6 use OSPF packet types described in Section 4.3
    of [OSPFV2], 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 remain the
    same.

Coltun, et al. Standards Track [Page 13] RFC 5340 OSPF for IPv6 July 2008

 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.
 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 [OSPFV2].
 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 [OSPFV2].
 o  The neighbor state machine, including the list of OSPF neighbor
    states and events, remains unchanged.  The neighbor state machine
    is described in Sections 10.1, 10.2, 10.3, and 10.4 of [OSPFV2].
 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
    [OSPFV2].
 However, some OSPF protocol mechanisms have changed as previously
 described in Section 2 herein.  These changes are explained in detail
 in the following subsections, making references to the appropriate
 sections of [OSPFV2].
 The following subsections provide a recipe for turning an IPv4 OSPF
 implementation into an IPv6 OSPF implementation.

4.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 [OSPFV2], 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 that have AS flooding scope.  LSAs with unknown LS

Coltun, et al. Standards Track [Page 14] RFC 5340 OSPF for IPv6 July 2008

    type, U-bit set to 1 (flood even when unrecognized), and AS
    flooding scope also appear in the top-level data structure.

4.1.1. The Area Data Structure

 The IPv6 area data structure contains all elements defined for IPv4
 areas in Section 6 of [OSPFV2].  In addition, all LSAs of known type
 that 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.  NSSA-LSAs are also included in an NSSA area's
 data structure.

4.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 [OSPFV2]) 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 ([INTFMIB])
    as the Interface ID.  The Interface ID appears in Hello packets
    sent out the interface, the link-local-LSA originated by the
    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.
    The Interface ID for a virtual link is independent of the
    Interface ID of the outgoing interface it traverses in the transit
    area.
 Instance ID
    Every interface is assigned an Instance ID.  This should default
    to 0.  It is only necessary to assign a value other than 0 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 assigned an Instance ID of 0 and all the
    routers in the first community will be assigned 0 as the Instance
    ID for interfaces connected to the ethernet segment.  An Instance
    ID of 1 is assigned to the other routers' interfaces connected to
    the ethernet segment.  The OSPF transmit and receive processing
    (see Section 4.2) will then keep the two communities separate.

Coltun, et al. Standards Track [Page 15] RFC 5340 OSPF for IPv6 July 2008

 List of LSAs with link-local scope
    All LSAs with link-local scope and that were originated/flooded on
    the link belong to the interface structure that connects to the
    link.  This includes the collection of the link's link-LSAs.
 IP interface address
    For IPv6, the IPv6 address appearing in the source of OSPF packets
    sent on the interface is almost always a link-local address.  The
    one exception is for virtual links that MUST use one of the
    router's own 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 on the interface.  In
 addition, OSPF for IPv6 relies on the IP Authentication Header (see
 [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) as
 described in [OSPFV3-AUTH] to ensure integrity and authentication/
 confidentiality of routing exchanges.  For this reason, AuType and
 Authentication key are not associated with IPv6 OSPF interfaces.
 Interface states, events, and the interface state machine remain
 unchanged from IPv4 as documented in Sections 9.1, 9.2, and 9.3 of
 [OSPFV2] respectively.  The Designated Router and Backup Designated
 Router election algorithm also remains unchanged from the IPv4
 election in Section 9.4 of [OSPFV2].

4.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 when such 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 [OSPFV2]
 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 or point-to-multipoint
    link to the neighbor or b) advertising a link to a network where
    the neighbor has become the Designated Router.

Coltun, et al. Standards Track [Page 16] RFC 5340 OSPF for IPv6 July 2008

 Neighbor IP address
    The neighbor's IPv6 address contained as the source address in
    OSPF for IPv6 packets.  This will be an IPv6 link-local address
    for all link types except virtual links.
 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 Backup 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 as documented in Sections 10.1, 10.2, and 10.3 of
 [OSPFV2] respectively.  The decision as to which adjacencies to form
 also remains unchanged from the IPv4 logic documented in Section 10.4
 of [OSPFV2].

4.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 OSPF for IPv4, OSPF for 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 IPv6, encoded by the Type
 field of the standard OSPF packet header.

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

Coltun, et al. Standards Track [Page 17] RFC 5340 OSPF for IPv6 July 2008

 Packet length
    The length of the entire OSPF packet in bytes, including the
    standard OSPF packet header.
 Router ID
    The identity of the router itself (who is originating the packet).
 Area ID
    The OSPF area for the interface on which the packet is being sent.
 Instance ID
    The OSPF Instance ID associated with the interface out of which
    the packet is being sent.
 Checksum
    The standard IPv6 Upper-Layer checksum (as described in Section
    8.1 of [IPV6]) covering the entire OSPF packet and prepended IPv6
    pseudo-header (see Appendix 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 [OSPFV2].  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 [OSPFV2] respectively.
 Sending Hello packets is documented in Section 4.2.1.1, and the
 sending of Database Description packets in Section 4.2.1.2.  The
 sending of Link State Update packets is documented in Section 4.5.2.

4.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 [OSPFV2]):
 o  Before the Hello packet is sent on 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 since OSPF
    for IPv6 runs per-link instead of per-subnet.
 o  The choice of Designated Router and Backup Designated Router is
    now indicated within Hellos by their Router IDs instead of by
    their IP interface addresses.  Advertising the Designated Router

Coltun, et al. Standards Track [Page 18] RFC 5340 OSPF for IPv6 July 2008

    (or Backup Designated Router) as 0.0.0.0 indicates that the
    Designated Router (or Backup Designated Router) has not yet been
    chosen.
 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 as follows.  The
    E-bit is set if and only if the interface attaches to a regular
    area, i.e., not a stub or NSSA area.  Similarly, the N-bit is set
    if and only if the interface attaches to an NSSA area (see
    [NSSA]).  Finally, the DC-bit is set if and only if the router
    wishes to suppress the sending of future Hellos over the interface
    (see [DEMAND]).  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 [OSPFV2].

4.2.1.2. Sending Database Description Packets

 The sending of Database Description packets differs from Section 10.8
 of [OSPFV2] 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 as follows.  The DC-bit is set if and only
    if the router wishes to suppress the sending of Hellos over the
    interface (see [DEMAND]).  Unrecognized bits in the Database
    Description packet's Options field should be cleared.

4.2.2. Receiving Protocol Packets

 Whenever a router receives an OSPF protocol packet, it is marked with
 the interface on which it was received.  For routers that have
 virtual links configured, it may not be immediately obvious with
 which interface to associate the packet.  For example, consider the
 Router RT11 depicted in Figure 6 of [OSPFV2].  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:

Coltun, et al. Standards Track [Page 19] RFC 5340 OSPF for IPv6 July 2008

 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), one of the IPv6 multicast
    addresses AllSPFRouters or AllDRouters, or an IPv6 global address
    (for virtual links).
 o  The Next Header field of the immediately encapsulating IPv6 header
    MUST specify the OSPF protocol (89).
 o  Any encapsulating IP Authentication Headers (see [IPAUTH]) and the
    IP Encapsulating Security Payloads (see [IPESP]) MUST be processed
    and/or verified to ensure integrity and authentication/
    confidentiality of OSPF routing exchanges.  This is described in
    [OSPFV3-AUTH].
 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 OSPFv3 interface.  If they do not,
 the packet SHOULD be discarded:
 o  The version number field MUST specify protocol version 3.
 o  The IPv6 Upper-Layer checksum (as described in Section 8.1 of
    [IPV6]), covering the entire OSPF packet and prepended IPv6
    pseudo-header, must be verified (see Appendix A.3.1).
 o  The Area ID and Instance ID found in the OSPF header must be
    verified.  If both of the following cases fail, the packet should
    be discarded.  The Area ID and Instance ID specified in the header
    must either:
    1.  Match one of the Area ID(s) and Interface Instance ID(s) for
        the receiving link.  Unlike IPv4, the IPv6 source address is
        not restricted to lie within the same IPv6 subnet as the
        receiving link.  IPv6 OSPF runs per-link instead of per-IP-
        subnet.
    2.  Match the backbone area and other criteria for a configured
        virtual link.  The receiving router must be an ABR (Area
        Border Router) and the Router ID specified in the packet (the
        source router) must be the other end of a configured virtual
        link.  Additionally, the receiving link must have an OSPFv3
        interface that attaches to the virtual link's configured
        transit area and the Instance ID must match the virtual link's
        Instance ID.  If all of these checks succeed, the packet is
        accepted and is associated with the virtual link (and the
        backbone area).

Coltun, et al. Standards Track [Page 20] RFC 5340 OSPF for IPv6 July 2008

 o  Locally originated packets SHOULD NOT be processed by OSPF except
    for support of multiple interfaces attached to the same link as
    described in Section 4.9.  Locally originated packets have a
    source address equal to one of the router's local addresses.
 o  Packets whose IPv6 destination is AllDRouters should only be
    accepted if the state of the receiving OSPFv3 interface is DR or
    Backup (see Section 9.1 [OSPFV2]).
 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 packet processing as described in Section 4.2.2.1.  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 in
 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 is almost
 identical to the IPv4 procedures documented in Sections 10.6, 10.7,
 and 13.7 of [OSPFV2] respectively with the exceptions noted below.
 o  LSAs with unknown LS types in Database Description packets that
    have an acceptable flooding scope are processed the same as LSAs
    with known LS types.  In OSPFv2 [OSPFV2], these would result in
    the adjacency being brought down with a SequenceMismatch event.
 The receiving of Hello packets is documented in Section 4.2.2.1 and
 the receiving of Link State Update packets is documented in
 Section 4.5.1.

4.2.2.1. Receiving Hello Packets

 The receive processing of Hello packets differs from Section 10.5 of
 [OSPFV2] 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.

Coltun, et al. Standards Track [Page 21] RFC 5340 OSPF for IPv6 July 2008

 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.

4.3. The Routing table Structure

 The routing table used by OSPF for IPv4 is defined in Section 11 of
 [OSPFV2].  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 4.8).
 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
 [OSPFV2]) 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 routers.
 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
 Appendix A.4.10).

Coltun, et al. Standards Track [Page 22] RFC 5340 OSPF for IPv6 July 2008

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

4.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, AS-external-LSAs, and
 NSSA-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-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 [OSPFV2] and is not encoded
 within OSPF for IPv6's LSAs.
 These changes will be described in detail in the following
 subsections.

4.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 [OSPFV2], respectively.  However, the following fields
 have changed for IPv6:
 Options
    The Options field has been removed from the standard 20-byte LSA
    header and moved 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 Appendix A.2).  Additionally, 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 high-order bit encoding the handling of unknown types and the
    next two bits encoding flooding scope.  See Appendix A.4.2.1 for
    the current coding of the LS type field.

Coltun, et al. Standards Track [Page 23] RFC 5340 OSPF for IPv6 July 2008

 Link State ID
    The Link State ID remains at 32 bits in length.  However, except
    for network-LSAs and link-LSAs, the 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.

4.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 [OSPFV2]).
 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 4.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 4.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, NSSA-
 LSAs, and intra-area-prefix-LSAs.  LSAs with an unknown LS type, the
 U-bit set to 0, and/or link-local flooding scope are contained within
 the appropriate interface structure (see Section 4.1.2); this
 includes link-LSAs.
 To look up or install an LSA in the database, you first examine the
 LS type and the LSA's context (i.e., the area or link to which the
 LSA belongs).  This information allows you to find the correct
 database of LSAs where you then search based on the LSA's type, Link
 State ID, and Advertising Router.

Coltun, et al. Standards Track [Page 24] RFC 5340 OSPF for IPv6 July 2008

4.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 on the appropriate interfaces.
 The list of events causing LSAs to be reoriginated for IPv4 is given
 in Section 12.4 of [OSPFV2].  The following events and/or actions are
 added for IPv6:
 o  The state or interface ID 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.  If
    the router is the Designated Router, the router may also need to
    (re)originate and/or flush the network-LSA corresponding to the
    interface.
 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.
 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.
 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 the Designated Router for
    the link, it originates a new intra-area-prefix-LSA.
 o  A new link-LSA is received, causing the logical OR of LSA options
    advertised by adjacent routers on the link to change.  If the
    router is the Designated Router for the link, it originates a new
    network-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 [OSPFV2] has been reworked to
 show IPv6 addressing, resulting in Figure 1.  The OSPF cost of each

Coltun, et al. Standards Track [Page 25] RFC 5340 OSPF for IPv6 July 2008

 interface is 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 2001:0db8:c001::/48.  The
 OSPF interface IDs and the link-local addresses for the router
 interfaces in Figure 1 are given in Table 2.
        ..........................................
        .                                  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        2001:0db8:c001:0200::/56
               N2        2001:0db8:c001:0300::/56
               N3        2001:0db8:c001:0100::/56
               N4        2001:0db8:c001:0400::/56
        Table 1: IPv6 Link Prefixes for Sample Network

Coltun, et al. Standards Track [Page 26] RFC 5340 OSPF for IPv6 July 2008

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

4.4.3.1. LSA Options

 The Options field in LSAs should be coded as follows.  The V6-bit
 should be set unless the router will not participate in transit IPv6
 routing.  The E-bit should be clear if and only if the attached area
 is an OSPF stub or OSPF NSSA area.  The E-bit should always be set in
 AS scoped LSAs.  The N-bit should be set if and only if the attached
 area is an OSPF NSSA area.  The R-bit should be set unless the router
 will not participate in any transit routing.  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 [DEMAND]).  All
 unrecognized bits in the Options field should be cleared.
 The V6-bit and R-bit are only examined in Router-LSAs during the SPF
 computation.  In other LSA types containing options, they are set for
 informational purposes only.

4.4.3.2. 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 attached to the area.  When
 multiple router-LSAs are used, they are distinguished by their Link
 State ID fields.
 To the left of the Options field, the router capability bits V, E,
 and B should be set according to Section 12.4.1 of [OSPFV2].
 Each of the router's interfaces to the area is then described by
 appending "link descriptions" to the router-LSA.  Each link
 description is 16 bytes long, consisting of five fields: (link) Type,

Coltun, et al. Standards Track [Page 27] RFC 5340 OSPF for IPv6 July 2008

 Metric, Interface ID, Neighbor Interface ID, and Neighbor Router ID
 (see Appendix A.4.3).  Interfaces in the 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 (except in the case of multiple Standby
 Interfaces as described in Section 4.9).  All other interfaces to the
 area add zero, one, or more link descriptions.  The number and
 content of these depend on the interface type.  Within each link
 description, the Metric field is always set to 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.
 Broadcast and NBMA interfaces
    If the router is fully adjacent to the link's Designated Router or
    if the router itself is the 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 4.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 the
    Neighbor Interface ID field set to the Interface ID advertised by
    the neighbor in its Hello packets and the 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 the Designated Router of Network
 N3.

Coltun, et al. Standards Track [Page 28] RFC 5340 OSPF for IPv6 July 2008

      ; 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.0.2.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.0.2.4 ; RT4's Router ID
                      RT3's router-LSA for Area 1
 For example, if 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 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 for stub networks no longer appear in the router-LSA.
 Rather, they are included in intra-area-prefix-LSAs.

4.4.3.3. 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 with an elected Designated Router that is
 fully adjacent with at least one other router on the link.  The
 network-LSA is originated by the link's Designated Router and lists
 all routers on the link with which it is fully adjacent.
 The procedure for originating network-LSAs in IPv6 is the same as the
 IPv4 procedure documented in Section 12.4.2 of [OSPFV2], 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 originated by the link's
    Designated Router.

Coltun, et al. Standards Track [Page 29] RFC 5340 OSPF for IPv6 July 2008

 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 corresponding to fully adjacent neighbors.  In this way, the
    network link exhibits a capability when at least one fully
    adjacent neighbor on the link requests that the capability be
    advertised.
 As an example, assuming that Router RT4 has been elected the
 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.0.2.4 ;RT4's Router ID
      Options = (V6-bit|E-bit|R-bit)
             Attached Router = 192.0.2.4    ;Router ID
             Attached Router = 192.0.2.1    ;Router ID
             Attached Router = 192.0.2.2    ;Router ID
             Attached Router = 192.0.2.3    ;Router ID
                      Network-LSA for Network N3

4.4.3.4. 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 [OSPFV2], with the following exceptions:
 o  The Link State ID of an inter-area-prefix-LSA has lost all of its
    addressing semantics and 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.

Coltun, et al. Standards Track [Page 30] RFC 5340 OSPF for IPv6 July 2008

 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 2001:0db8:c001::/48.  The
 cost is set to 4, which is the maximum cost of all of the individual
 component prefixes.  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.0.2.4       ;RT4's ID
         Metric = 4                  ;maximum to components
         PrefixLength = 48
         PrefixOptions = 0
         Address Prefix = 2001:0db8:c001 ;padded to 64-bits
        Inter-area-prefix-LSA for Area 1 addresses originated
     by Router
                         RT4 into the backbone

4.4.3.5. 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 (i.e., an AS
 Boundary Router (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 [OSPFV2],
 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 and now 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.

Coltun, et al. Standards Track [Page 31] RFC 5340 OSPF for IPv6 July 2008

 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 [OSPFV2].  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.0.2.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
 Inter-area-router-LSA for AS boundary router RT7 originated by Router
                            RT4 into Area 1

4.4.3.6. 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 [OSPFV2], with the
 following exceptions:
 o  The Link State ID of an AS-external-LSA has lost all of its
    addressing semantics and 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.
 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.

Coltun, et al. Standards Track [Page 32] RFC 5340 OSPF for IPv6 July 2008

 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 supported through the inclusion of the Referenced LS Type
    field and the optional Referenced Link State ID field (the latter
    present if and only if the Referenced LS Type is non-zero).  This
    capability is for future use; the Referenced LS Type should be set
    to 0, and received non-zero values for this field should be
    ignored until its use is defined.
 As an example, consider the OSPF Autonomous System depicted in Figure
 6 of [OSPFV2].  Assume that RT7 has learned its route to N12 via BGP
 and that it wishes to advertise a Type 2 metric into the AS.  Also
 assume that the IPv6 prefix for N12 is the value 2001:0db8: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 in order 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         ;LSA type/scope unique identifier
      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
      Referenced LS Type = 0      ;no Referenced Link State ID
      Address Prefix = 2001:0db8:0a00 ;padded to 64-bits
      External Route Tag = as per BGP/OSPF interaction
       AS-external-LSA for Network N12, originated by Router RT7

4.4.3.7. NSSA-LSAs

 The LS type of an NSSA-LSA is set to the value 0x2007.  NSSA-LSAs
 have area flooding scope.  Each NSSA-LSA describes a path to a prefix
 external to the Autonomous System whose flooding scope is restricted
 to a single NSSA area.
 The procedure for originating NSSA-LSAs in IPv6 is the same as the
 IPv4 procedure documented in [NSSA], with the following exceptions:

Coltun, et al. Standards Track [Page 33] RFC 5340 OSPF for IPv6 July 2008

 o  The Link State ID of an NSSA-LSA has lost all of its addressing
    semantics and simply serves to distinguish multiple NSSA-LSAs that
    are originated by the same router in the same area.
 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.
 o  Link-local addresses can never be advertised in NSSA-LSAs.
 o  The forwarding address is present in the NSSA-LSA if and only if
    the NSSA-LSA's bit F is set.
 o  The external route tag is present in the NSSA-LSA if and only if
    the NSSA-LSA's bit T is set.
 o  The capability for an NSSA-LSA to reference another LSA has been
    supported through the inclusion of the Referenced LS Type field
    and the optional Referenced Link State ID field (the latter
    present if and only if the Referenced LS Type is non-zero).  This
    capability is for future use; the Referenced LS Type should be set
    to 0, and received non-zero values for this field should be
    ignored until its use is defined.
 An example of an NSSA-LSA would only differ from an AS-external-LSA
 in that the LS type would be 0x2007 rather than 0x4005.

4.4.3.8. 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 two or more (including the
 originating router itself) routers.  Link-LSAs SHOULD NOT be
 originated for virtual links.
 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.
 3.  They allow the router to advertise a collection of Options bits
     in the network-LSA originated by the Designated Router on a
     broadcast or NBMA link.

Coltun, et al. Standards Track [Page 34] RFC 5340 OSPF for IPv6 July 2008

 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 reflect the router's
    capabilities.  On multi-access links, the Designated Router will
    logically OR the link-LSA Options fields for all fully adjacent
    neighbors 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 4.8.2).
 o  Each IPv6 address prefix that has been configured on Link L is
    added to the link-LSA by specifying values for the PrefixLength,
    PrefixOptions, and Address Prefix fields.
 After building a link-LSA for a given link, the router installs the
 link-LSA into the associated interface data structure and floods the
 link-LSA on the link.  All other routers on the link will receive the
 link-LSA, but they will not flood the link-LSA on other links.
 If LinkLSASuppression is configured for the interface and the
 interface type is not broadcast or NBMA, origination of the link-LSA
 may be suppressed.  This implies that other routers on the link will
 ascertain the router's next-hop address using a mechanism other than
 the link-LSA (see Section 4.8.2).  Refer to Appendix C.3 for a
 description of the LinkLSASuppression interface configuration
 parameter.
 As an example, consider the link-LSA that RT3 will build for N3 in
 Figure 1.  Suppose that the prefix 2001:0db8:c001:0100::/56 has been
 configured within RT3 for N3.  This will result in the following
 link-LSA that RT3 will flood only on N3.  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 35] RFC 5340 OSPF for IPv6 July 2008

      ; 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.0.2.3 ;RT3's Router ID
      Rtr Priority = 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 = 2001:0db8:c001:0100 ;pad to 64-bits
                         RT3's link-LSA for N3

4.4.3.9. 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 either 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.  Each intra-area-prefix-LSA has a unique Link State ID and
 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 the
    Referenced LS Type is set to 0x2002, the Referenced Link State ID
    is set to the Designated Router's Interface ID on Link L, and the
    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

Coltun, et al. Standards Track [Page 36] RFC 5340 OSPF for IPv6 July 2008

    Router and the Link State ID matches the neighbor's interface ID,
    the list of prefixes in the link-LSA is copied into the 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
    PrefixOptions fields should be logically OR'ed together, and a
    single instance of the duplicate prefix should be included in 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 prefixes for
 its attached stub links, looped-back interfaces, and hosts.  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 the Referenced LS Type to 0x2001,
    the Referenced Link State ID to 0, and the 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 the 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), prefixes that will be
    included in the intra-area-prefix-LSA for the link are skipped.
    However, any prefixes that would normally have the LA-bit set
    SHOULD be advertised independent of whether or not the interface
    is advertised as a transit link.  If the interface type is point-
    to-multipoint or the interface is in the state Loopback, the
    global scope IPv6 addresses associated with the interface (if any)
    are copied into the intra-area-prefix-LSA with the PrefixOptions
    LA-bit set, the PrefixLength set to 128, and the metric set to 0.
    Otherwise, the list of 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 Appendix C.7) to the intra-area-prefix-
    LSA.

Coltun, et al. Standards Track [Page 37] RFC 5340 OSPF for IPv6 July 2008

 o  If RTX has one or more virtual links configured through the area,
    it includes one of its global scope IPv6 interface addresses in
    the LSA (if it hasn't already), setting the LA-bit in the
    PrefixOptions field, 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.

Coltun, et al. Standards Track [Page 38] RFC 5340 OSPF for IPv6 July 2008

      ; RT4's 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           ;LSA type/scope unique identifier
      Advertising Router = 192.0.2.4 ;RT4's Router ID
      # prefixes = 1
      Referenced LS Type = 0x2002 ;network-LSA reference
      Referenced Link State ID = 1
      Referenced Advertising Router = 192.0.2.4
      PrefixLength = 56           ;N3's prefix
      PrefixOptions = 0
      Metric = 0
      Address Prefix = 2001:0db8: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         ;LSA type/scope unique identifier
      Advertising Router = 192.0.2.3 ;RT3's Router ID
      # prefixes = 1
      Referenced LS Type = 0x2001 ;router-LSA reference
      Referenced Link State ID = 0
      Referenced Advertising Router = 192.0.2.3
      PrefixLength = 56           ;N4's prefix
      PrefixOptions = 0
      Metric = 2                  ;N4 interface cost
      Address Prefix = 2001:0db8:c001:0400 ;pad
               Intra-area-prefix-LSA for Network Link N3
 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 the 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 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 this case, the Designated Router may not

Coltun, et al. Standards Track [Page 39] RFC 5340 OSPF for IPv6 July 2008

 be running the other protocol suite, and so another of the link's
 routers may need to originate the intra-area-prefix-LSA.  In that
 case, the Referenced Advertising Router and Advertising Router would
 be different.

4.4.4. Future LSA Validation

 It is expected that new LSAs will be defined that will not be
 processed during the Shortest Path First (SPF) calculation as
 described in Section 4.8, for example, OSPFv3 LSAs corresponding to
 information advertised in OSPFv2 using opaque LSAs [OPAQUE].  In
 general, the new information advertised in future LSAs should not be
 used unless the OSPFv3 router originating the LSA is reachable.
 However, depending on the application and the data advertised, this
 reachability validation MAY be done less frequently than every SPF
 calculation.
 To facilitate inter-area reachability validation, any OSPFv3 router
 originating AS scoped LSAs is considered an AS Boundary Router
 (ASBR).

4.5. Flooding

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

4.5.1. Receiving Link State Update Packets

 The encoding of flooding scope in the LS type and the need to process
 unknown LS types cause modifications to the processing of received
 Link State Update packets.  As in IPv4, each LSA in a received Link

Coltun, et al. Standards Track [Page 40] RFC 5340 OSPF for IPv6 July 2008

 State Update packet is examined.  In IPv4, eight steps are executed
 for each LSA, as described in Section 13 of [OSPFV2].  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.  Discard the LSA and get
          the next one from the Link State Update packet if the
          interface area has been configured as a stub or
          NSSA area and the LS type indicates "AS flooding scope".
          This generalizes the IPv4 behavior where AS-external-LSAs
          and AS-scoped opaque LSAs [OPAQUE] are not flooded
          throughout stub or NSSA areas.
    (3)   Else if the flooding scope in the LSA's LS type 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 [OSPFV2] are also
 somewhat different for IPv6, as described in Sections 4.5.2 and 4.5.3
 below.

4.5.2. Sending Link State Update Packets

 The sending of Link State Update packets is described in Section 13.3
 of [OSPFV2].  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
 [OSPFV2]).  However, the list of eligible interfaces on 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 scope, the particular
    area or interface with which the LSA is associated.
 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 41] RFC 5340 OSPF for IPv6 July 2008

 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 on
    interfaces connecting to stub or NSSA areas.  If the flooding
    scope is "area flooding scope", the 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 is also the interface on which the LSA was
    received in a Link State Update packet).
 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 the type is understood).  In
    this case, select the eligible interfaces based on the encoded
    flooding scope the same as in Case 1 above.
 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 [OSPFV2]).  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 document,
 namely, router-LSAs (LS type 0x2001), network-LSAs (0x2002), inter-
 area-prefix-LSAs (0x2003), inter-area-router-LSAs (0x2004), NSSA-LSAs
 (0x2007), AS-external-LSAs (0x4005), link-LSAs (0x0008), and Intra-
 Area-Prefix-LSAs (0x2009), are assumed to be understood by all
 routers.  However, all LS types MAY not be understood by all routers.
 For example, a new LSA type with its U-bit set to 0 MAY only be
 understood by a subset of routers.  This new LS type should only be
 flooded to an OSPF neighbor that understands the LS type or when the
 neighbor is the Designated Router or Backup Designated Router for the
 attached link.

Coltun, et al. Standards Track [Page 42] RFC 5340 OSPF for IPv6 July 2008

 The previous paragraph solves a problem for IPv4 OSPF extensions,
 which require that the Designated Router support the extension in
 order to have the new LSA types flooded across broadcast and NBMA
 networks.

4.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 4.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 4.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 data 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 [OSPFV2].  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 4.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 [OSPFV2]).  If this destination
    is an AS boundary router, it may also be necessary to re-examine
    all the AS-external-LSAs.
 AS-external-LSAs and NSSA-LSAs
    The best route to the destination described by the AS-external-LSA
    or NSSA-LSA must be recalculated (see Section 16.6 in [OSPFV2] and
    Section 2.0 in [NSSA]).
 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.

4.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
 [OSPFV2].  For IPv6, self-originated LSAs are those LSAs whose
 Advertising Router is equal to the router's own Router ID.

Coltun, et al. Standards Track [Page 43] RFC 5340 OSPF for IPv6 July 2008

4.7. Virtual Links

 OSPF virtual links for IPv4 are described in Section 15 of [OSPFV2].
 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 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.
    Hence, a link-LSA SHOULD NOT be originated for a virtual link
    since the virtual link has no link-local address or associated
    prefixes.
 o  Likewise, the virtual neighbor's IPv6 address is an IPv6 address
    with 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 Section 4.4.3.9 and Section 4.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.

4.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 [OSPFV2].  High-level differences between the IPv6
 and IPv4 calculations include:
 o  Prefix information has been removed from router-LSAs and network-
    LSAs and is now advertised in intra-area-prefix-LSAs.  Whenever
    [OSPFV2] specifies that stub networks within router-LSAs be
    examined, IPv6 will instead examine prefixes within intra-area-
    prefix-LSAs.
 o  Type 3 and 4 summary-LSAs have been renamed inter-area-prefix-LSAs
    and inter-area-router-LSAs respectively.

Coltun, et al. Standards Track [Page 44] RFC 5340 OSPF for IPv6 July 2008

 o  Addressing information is no longer encoded in Link State IDs and
    is now only found within the body of LSAs.
 o  In IPv6, a router can originate multiple router-LSAs,
    distinguished by Link State ID, within a single area.  These
    router-LSAs MUST be treated as a single aggregate by the area's
    shortest-path calculation (see Section 4.8.1).
 For each area, the shortest-path tree calculation creates routing
 table entries for the area's routers and transit links (see
 Section 4.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 4.8.3.
 Events generated as a result of routing table changes (Section 16.7
 of [OSPFV2]) and the equal-cost multipath logic (Section 16.8 of
 [OSPFV2]) are identical for both IPv4 and IPv6.

4.8.1. Calculating the Shortest-Path Tree for an Area

 The IPv4 shortest-path calculation is contained in Section 16.1 of
 [OSPFV2].  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 4.3).
 Section 16.1 of [OSPFV2] 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 [OSPFV2]):
 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.
 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 the Advertising Router set to V's
    OSPF Router ID MUST be processed as an aggregate, treating them as
    fragments of a single large router-LSA.  The Options field and the

Coltun, et al. Standards Track [Page 45] RFC 5340 OSPF for IPv6 July 2008

    router type bits (bits Nt, V, E, and B) should always be taken
    from the router-LSA 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 and the router-LSA V6-bit or R-bit is
    not set in the LSA options, the transit link W is ignored and V's
    next link is examined.
 o  In Step 2b, if W is a router, there may again be multiple LSAs
    associated with the router.  All router-LSAs with the Advertising
    Router set to W's OSPF Router ID MUST be 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 rather than 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 with the LA-bit set.
 o  Routing table entries for transit networks, which are no longer
    associated with IP networks, are also calculated in Step 4 and
    added to the per-area routing table.
 The next stage of the shortest-path calculation proceeds similarly to
 the two steps of the second stage of Section 16.1 in [OSPFV2].
 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's 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's routing table entry for the area.
 This specification does not require that the above algorithm be used
 to calculate the intra-area shortest-path tree.  However, if another
 algorithm or optimization is used, an identical shortest-path tree
 must be produced.  It is also important that any alternate algorithm
 or optimization maintain the requirement that transit vertices must

Coltun, et al. Standards Track [Page 46] RFC 5340 OSPF for IPv6 July 2008

 be bidirectional for inclusion in the tree.  Alternate algorithms and
 optimizations are beyond the scope of this specification.

4.8.2. 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 [OSPFV2]).  However,
 there are some differences.  When calculating the next-hop IPv6
 address for a router (call it Router X) that shares a link with the
 calculating router, the calculating router assigns the next-hop IPv6
 address to be the link-local interface address contained in Router
 X's link-LSA (see Appendix A.4.9) for the link.  This procedure is
 necessary for some link types, for example NBMA, where the two
 routers need not be neighbors and might not be exchanging OSPF Hello
 packets.  For other link types, the next-hop address may be
 determined via the IPv6 source address in the neighbor's Hello
 packet.
 Additionally, when calculating routes for the area's intra-area-
 prefix-LSAs, the parent vertex can be either a router-LSA or network-
 LSA.  This is in contrast to the second stage of the OSPFv2 intra-
 area SPF (Section 16.1 in [OSPFV2]) where the parent vertex is always
 a router-LSA.  In the case where the intra-area-prefix-LSA's
 referenced LSA is a directly connected network-LSA, the prefixes are
 also considered to be directly connected.  In this case, the next hop
 is solely the outgoing link and no IPv6 next-hop address is selected.

4.8.3. 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 [OSPFV2], 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 an
    advertised AS boundary 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 PrefixOptions field should
    be ignored by the inter-area route calculation.

Coltun, et al. Standards Track [Page 47] RFC 5340 OSPF for IPv6 July 2008

 When a single inter-area-prefix-LSA or inter-area-router-LSA has
 changed, the incremental calculations outlined in Section 16.5 of
 [OSPFV2] can be performed instead of recalculating the entire routing
 table.

4.8.4. 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 [OSPFV2],
 modified in the same way as the IPv6 inter-area route calculation in
 Section 4.8.3.

4.8.5. Calculating AS External and NSSA Routes

 The IPv6 AS external route calculation proceeds along the same lines
 as the IPv4 calculation in Section 16.4 of [OSPFV2] and Section 2.5
 of [NSSA], with the following exceptions:
 o  The Link State ID of the AS-external-LSA and NSSA-LSA types no
    longer encodes the network described by the LSA.  Instead, an
    address prefix is contained in the body of the LSA.
 o  The default route in AS-external-LSAs or NSSA-LSAs is advertised
    by a zero-length prefix.
 o  Instead of comparing the AS-external-LSA's or NSSA-LSA's
    Forwarding Address field to 0.0.0.0 to see whether a forwarding
    address has been used, the bit F in the respective 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 PrefixOptions field should
    be ignored by the inter-area route calculation.
 o  AS Boundary Router (ASBR) and forwarding address selection will
    proceed the same as if RFC1583Compatibility is disabled.
    Furthermore, RFC1583Compatibility is not an OSPF for IPv6
    configuration parameter.  Refer to Appendix C.1.
 When a single AS-external-LSA or NSSA-LSA has changed, the
 incremental calculations outlined in Section 16.6 of [OSPFV2] can be
 performed instead of recalculating the entire routing table.

4.9. Multiple Interfaces to a Single Link

 In OSPF for IPv6, a router may have multiple interfaces to a single
 link associated with the same OSPF instance and area.  All interfaces

Coltun, et al. Standards Track [Page 48] RFC 5340 OSPF for IPv6 July 2008

 will be used for the reception and transmission of data traffic while
 only a single interface sends and receives OSPF control traffic.  In
 more detail:
 o  Each of the multiple interfaces is assigned a different Interface
    ID.  A router will automatically detect that multiple interfaces
    are attached to the same link when a Hello packet is received with
    one of the router's link-local addresses as the source address and
    an Interface ID other than the Interface ID of the receiving
    interface.
 o  Each of the multiple interfaces MUST be configured with the same
    Interface Instance ID to be considered on the same link.  If an
    interface has multiple Instance IDs, it will be grouped with other
    interfaces based on matching Instance IDs.  Each Instance ID will
    be treated uniquely with respect to groupings of multiple
    interfaces on the same link.  For example, if interface A is
    configured with Instance IDs 1 and 35, and interface B is
    configured with Instance ID 35, interface B may be the Active
    Interface for Instance ID 35 but interface A will be active for
    Instance ID 1.
 o  The router will ignore OSPF packets other than Hello packets on
    all but one of the interfaces attached to the link.  It will only
    send its OSPF control packets (including Hello packets) on a
    single interface.  This interface is designated the Active
    Interface and other interfaces attached to the same link will be
    designated Standby Interfaces.  The choice of the Active Interface
    is implementation dependent.  For example, the interface with the
    highest Interface ID could be chosen.  If the router is elected
    Designated Router, it will be the Active Interface's Interface ID
    that will be used as the network-LSA's Link State ID.
 o  All of the interfaces to the link (Active and Standby) will appear
    in the router-LSA.  In addition, a link-LSA will be generated for
    each of the interfaces.  In this way, all interfaces will be
    included in OSPF's routing calculations.
 o  Any link-local scope LSAs that are originated for a Standby
    Interface will be flooded over the Active Interface.
    If a Standby Interface goes down, then the link-local scope LSAs
    originated for the Standby Interfaces MUST be flushed on the
    Active Interface.
 o  Prefixes on Standby Interfaces will be processed the same way as
    prefixes on the Active Interface.  For example, if the router is
    the DR for the link, the Active Interface's prefixes are included

Coltun, et al. Standards Track [Page 49] RFC 5340 OSPF for IPv6 July 2008

    in an intra-area-prefix-LSA which is associated with the Active
    Interface's network-LSA; prefixes from Standby Interfaces on the
    link will also be included in that intra-area-prefix LSA.
    Similarly, if the link is a stub link, then the prefixes for the
    Active and Standby Interfaces will all be included in the same
    intra-area-prefix-LSA that is associated with the router-LSA.
 o  If the Active Interface fails, a new Active Interface will have to
    take over.  The new Active Interface SHOULD form all new neighbor
    adjacencies with routers on the link.  This failure can be
    detected when the router's other interfaces to the Active
    Interface's link cease to hear the router's Hellos or through
    internal mechanisms, e.g., monitoring the Active Interface's
    status.
 o  If the network becomes partitioned with different local interfaces
    attaching to different network partitions, multiple interfaces
    will become Active Interfaces and function independently.
 o  During the SPF calculation when a network-LSA for a network that
    is directly connected to the root vertex is being examined, all of
    the multiple interfaces to the link of adjacent router-LSAs must
    be used in the next-hop calculation.
    This can be accomplished during the back link check (see Section
    16.1, Step 2 (B), in [OSPFV2]) by examining each link of the
    router-LSA and making a list of the links that point to the
    network-LSA.  The Interface IDs for links in this list are then
    used to find the corresponding link-LSAs and the link-local
    addresses used as next hops when installing equal-cost paths in
    the routing table.
 o  The interface state machine is modified to add the state Standby.
    See Section 4.9.1 for a description of the Standby state.

4.9.1. Standby Interface State

 In this state, the interface is one of multiple interfaces to a link
 and this interface is designated Standby and is not sending or
 receiving control packets.  The interface will continue to receive
 the Hello packets sent by the Active Interface.  The interface will
 maintain a timer, the Active Interface Timer, with the same interval
 as the RouterDeadInterval.  This timer will be reset whenever an OSPF
 Hello packet is received from the Active Interface to the link.
 Two new events are added to the list of events that cause interface
 state changes: MultipleInterfacesToLink and ActiveInterfaceDead.  The
 descriptions of these events are as follows:

Coltun, et al. Standards Track [Page 50] RFC 5340 OSPF for IPv6 July 2008

 MultipleInterfacesToLink
    An interfaces on the router has received a Hello packet from
    another interface on the same router.  One of the interfaces is
    designated as the Active Interface and the other interface is
    designated as a Standby Interface.  The Standby Interface
    transitions to the Standby state.
 ActiveInterfaceDead
    There has been an indication that a Standby Interface is no longer
    on a link with an Active Interface.  The firing of the Active
    Interface Timer is one indication of this event, as it indicates
    that the Standby Interface has not received an OSPF Hello packet
    from the Active Interface for the RouterDeadInterval.  Other
    indications may come from internal notifications, such as the
    Active Interface being disabled through a configuration change.
    Any indication internal to the router, such that the router knows
    the Active Interface is no longer active on the link, can trigger
    the ActiveInterfaceDead event for a Standby Interface.
 Interface state machine additions include:
      State(s):  Waiting, DR Other, Backup, or DR
         Event:  MultipleInterfacesToLink
     New state:  Standby
        Action:  All interface variables are reset and interface
                 timers disabled.  Also, all neighbor connections
                 associated with the interface are destroyed.  This
                 is done by generating the event KillNbr on all
                 associated neighbors.  The Active Interface Timer is
                 started and the interface will listen for OSPF Hello
                 packets from the link's Active Interface.
      State(s):  Standby
         Event:  ActiveInterfaceDead
     New state:  Down
        Action:  The Active Interface Timer is first disabled.  Then
                 the InterfaceUp event is invoked.
               Standby Interface State Machine Additions

Coltun, et al. Standards Track [Page 51] RFC 5340 OSPF for IPv6 July 2008

5. Security Considerations

 When running over IPv6, OSPFv3 relies on the IP Authentication Header
 (see [IPAUTH]) and the IP Encapsulating Security Payload (see
 [IPESP]) to ensure integrity and authentication/confidentiality of
 protocol packets.  This is described in [OSPFV3-AUTH].
 Most OSPFv3 implementations will be running on systems that support
 multiple protocols with their own independent security assumptions
 and domains.  When IPsec is used to protect OSPFv3 packets, it is
 important for the implementation to check the IPsec Security
 Association (SA) and local SA database to ensure the OSPF packet
 originated from a source that is trusted for OSPFv3.  This is
 required to eliminate the possibility that the packet was
 authenticated using an SA defined for another protocol running on the
 same system.
 The mechanisms in [OSPFV3-AUTH] do not provide protection against
 compromised, malfunctioning, or misconfigured routers.  Such routers
 can, either accidentally or deliberately, cause malfunctions
 affecting the whole routing domain.  The reader is encouraged to
 consult [GENERIC-THREATS] for a more comprehensive description of
 threats to routing protocols.

6. Manageability Considerations

 The Management Information Base (MIB) for OSPFv3 is defined in
 [OSPFV3-MIB].

7. IANA Considerations

 Most OSPF for IPv6 IANA considerations are documented in [OSPF-IANA].
 IANA has updated the reference for RFC 2740 to this document.
 Additionally, this document introduces the following IANA
 requirements that were not present in [OSPFV3]:
 o  Reserves the options with the values 0x000040 and 0x000080 for
    migrated OSPFv2 options in the OSPFv3 Options registry defined in
    [OSPF-IANA].  For information on the OSPFv3 Options field, refer
    to Appendix A.2.
 o  Adds the prefix option P-bit with value 0x08 to the OSPFv3 Prefix
    Options registry defined in [OSPF-IANA].  For information on
    OSPFv3 Prefix Options, refer to Appendix A.4.1.1.

Coltun, et al. Standards Track [Page 52] RFC 5340 OSPF for IPv6 July 2008

 o  Adds the prefix option DN-bit with value 0x10 to the OSPFv3 Prefix
    Options registry defined in [OSPF-IANA].  For information on
    OSPFv3 Prefix Options, refer to Appendix A.4.1.1.

7.1. MOSPF for OSPFv3 Deprecation IANA Considerations

 With the deprecation of MOSPF for OSPFv3, the following code points
 are available for reassignment.  Refer to [OSPF-IANA] for information
 on the respective registries.  This document:
 o  Deprecates the MC-bit with value 0x000004 in the OSPFv3 Options
    registry.
 o  Deprecates Group-membership-LSA with value 6 in OSPFv3 LSA
    Function Code registry.
 o  Deprecates MC-bit with value 0x04 in the OSPFv3 Prefix Options
    registry.
 The W-bit in the OSPFv3 Router Properties has also been deprecated.
 This requires a new registry for OSPFv3 router properties since it
 will diverge from the OSPFv2 Router Properties.
    Registry Name: OSPFv3 Router Properties Registry
    Reference: RFC 5340
    Registration Procedures: Standards Action
    Registry:
    Value   Description    Reference
    ------  -------------  ---------
    0x01    B-bit          RFC 5340
    0x02    E-bit          RFC 5340
    0x04    V-bit          RFC 5340
    0x08    Deprecated     RFC 5340
    0x10    Nt-bit         RFC 5340
                   OSPFv3 Router Properties Registry

8. Acknowledgments

 The RFC text was produced using Marshall Rose's xml2rfc tool.
 The following individuals contributed comments that were incorporated
 into this document:
 o  Harold Rabbie for his description of protocol details that needed
    to be clarified for OSPFv3 NSSA support.

Coltun, et al. Standards Track [Page 53] RFC 5340 OSPF for IPv6 July 2008

 o  Nic Neate for his pointing out that there needed to be changes for
    unknown LSA types handling in the processing of Database
    Description packets.
 o  Jacek Kwiatkowski for being the first to point out that the V6-
    and R-bits are not taken into account in the OSPFv3 intra-area SPF
    calculation.
 o  Michael Barnes recognized that the support for multiple interfaces
    to a single link was broken (see Section 4.9) and provided the
    description of the current protocol mechanisms.  Abhay Roy
    reviewed and suggested improvements to the mechanisms.
 o  Alan Davey reviewed and commented on document revisions.
 o  Vivek Dubey reviewed and commented on document revisions.
 o  Manoj Goyal and Vivek Dubey complained enough about link-LSAs
    being unnecessary to compel introduction of the LinkLSASuppression
    interface configuration parameter.
 o  Manoj Goyal for pointing out that the next-hop calculation for
    intra-area-prefix-LSAs corresponding to network vertices was
    unclear.
 o  Ramana Koppula reviewed and commented on document revisions.
 o  Paul Wells reviewed and commented on document revisions.
 o  Amir Khan reviewed and commented on document revisions.
 o  Dow Street and Wayne Wheeler commented on the addition of the DN-
    bit to OSPFv3.
 o  Mitchell Erblichs provided numerous editorial comments.
 o  Russ White provided numerous editorial comments.
 o  Kashima Hiroaki provided editorial comments.
 o  Sina Mirtorabi suggested that OSPFv3 should be aligned with OSPFv2
    with respect to precedence and should map it to IPv6 traffic class
    as specified in RFC 2474.  Steve Blake helped with the text.
 o  Faraz Shamin reviewed a late version of the document and provided
    editorial comments.

Coltun, et al. Standards Track [Page 54] RFC 5340 OSPF for IPv6 July 2008

 o  Christian Vogt performed the General Area Review Team (Gen-ART)
    review and provided comments.
 o  Dave Ward, Dan Romascanu, Tim Polk, Ron Bonica, Pasi Eronen, and
    Lars Eggert provided comments during the IESG review.  Also,
    thanks to Pasi for the text in Section 5 relating to routing
    threats.

9. References

9.1. Normative References

 [DEMAND]           Moy, J., "Extending OSPF to Support Demand
                    Circuits", RFC 1793, April 1995.
 [DIFF-SERV]        Nichols, K., Blake, S., Baker, F., and D. Black,
                    "Definition of the Differentiated Services Field
                    (DS Field) in the IPv4 and IPv6 Headers",
                    RFC 2474, December 1998.
 [DN-BIT]           Rosen, E., Peter, P., and P. Pillay-Esnault,
                    "Using a Link State Advertisement (LSA) Options
                    Bit to Prevent Looping in BGP/MPLS IP Virtual
                    Private Networks (VPNs)", RFC 4576, June 2006.
 [INTFMIB]          McCloghrie, K. and F. Kastenholz, "The Interfaces
                    Group MIB", RFC 2863, June 2000.
 [IP6ADDR]          Hinden, R. and S. Deering, "IP Version 6
                    Addressing Architecture", RFC 4291, February 2006.
 [IPAUTH]           Kent, S., "IP Authentication Header", RFC 4302,
                    December 2005.
 [IPESP]            Kent, S., "IP Encapsulating Security Payload
                    (ESP)", RFC 4303, December 2005.
 [IPV4]             Postal, J., "Internet Protocol", STD 5, RFC 791,
                    September 1981.
 [IPV6]             Deering, S. and R. Hinden, "Internet Protocol,
                    Version 6 (IPv6) Specification", RFC 2460,
                    December 1998.
 [NSSA]             Murphy, P., "The OSPF Not-So-Stubby Area (NSSA)
                    Option", RFC 3101, January 2003.

Coltun, et al. Standards Track [Page 55] RFC 5340 OSPF for IPv6 July 2008

 [OSPF-IANA]        Kompella, K. and B. Fenner, "IANA Considerations
                    for OSPF", BCP 130, RFC 4940, July 2007.
 [OSPFV2]           Moy, J., "OSPF Version 2", STD 54, RFC 2328,
                    April 1998.
 [OSPFV3-AUTH]      Gupta, M. and N. Melam, "Authentication/
                    Confidentiality for OSPFv3", RFC 4552, June 2006.
 [RFC-KEYWORDS]     Bradner, S., "Key words for use in RFCs to
                    Indicate Requirement Levels", BCP 14, RFC 2119,
                    March 1997.

9.2. Informative References

 [GENERIC-THREATS]  Barbir, A., Murphy, S., and Y. Yang, "Generic
                    Threats to Routing Protocols", RFC 4593,
                    October 2006.
 [MOSPF]            Moy, J., "Multicast Extensions to OSPF", RFC 1584,
                    March 1994.
 [MTUDISC]          Mogul, J. and S. Deering, "Path MTU discovery",
                    RFC 1191, November 1990.
 [OPAQUE]           Coltun, R., "The OSPF Opaque LSA Option",
                    RFC 2370, July 1998.
 [OSPFV3]           Coltun, R., Ferguson, D., and J. Moy, "OSPF for
                    IPv6", RFC 2740, December 1999.
 [OSPFV3-MIB]       Joyal, D. and V. Manral, "Management Information
                    Base for OSPFv3", Work in Progress,
                    September 2007.
 [SERV-CLASS]       Babiarz, J., Chan, K., and F. Baker,
                    "Configuration Guidelines for DiffServ Service
                    Classes", RFC 4594, August 2006.

Coltun, et al. Standards Track [Page 56] RFC 5340 OSPF for IPv6 July 2008

Appendix 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 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, Link State Request, Link State Update, and
 Link State Acknowledgment packets) can usually be split into multiple
 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 size of OSPF
 packets sent over virtual links to 1280 bytes unless Path MTU
 Discovery is being performed [MTUDISC].
 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. b

Coltun, et al. Standards Track [Page 57] RFC 5340 OSPF for IPv6 July 2008

    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.
 o  The OSPFv2 specification (Appendix A.1 in [OSPFV2]) indicates that
    OSPF protocol packets are sent with IP precedence set to
    Internetwork Control (B'110') [IPV4].  If routers in the OSPF
    routing domain map their IPv6 Traffic Class octet to the
    Differentiated Services Code Point (DSCP) as specified in
    [DIFF-SERV], then OSPFv3 packets SHOULD be sent with their DSCP
    set to CS6 (B'110000'), as specified in [SERV-CLASS].  In networks
    supporting this mapping, OSPF packets will be given precedence
    over IPv6 data traffic.

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; 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;
 these mismatches are discovered by examining LSAs.

Coltun, et al. Standards Track [Page 58] RFC 5340 OSPF for IPv6 July 2008

 Seven 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 Options bits in received Hello
 packets, Database Description packets, or LSAs should ignore the
 unrecognized bits and process the packet or LSA normally.
                             1                    2
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8  9 0 1  2  3
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+
        | | | | | | | | | | | | | | | | |*|*|DC|R|N|x| E|V6|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+
                         The Options field
                           The Options field
 V6-bit
    If this bit is clear, the router/link should be excluded from IPv6
    routing calculations.  See Section 4.8 for details.
 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 [OSPFV2].
 x-Bit
    This bit was previously used by MOSPF (see [MOSPF]), which has
    been deprecated for OSPFv3.  The bit should be set to 0 and
    ignored when received.  It may be reassigned in the future.
 N-bit
    This bit indicates whether or not the router is attached to an
    NSSA as specified in [NSSA].
 R-bit
    This bit (the `Router' bit) indicates whether the originator is an
    active router.  If the router bit is clear, then routes that
    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 [DEMAND].

Coltun, et al. Standards Track [Page 59] RFC 5340 OSPF for IPv6 July 2008

  • -bit

These bits are reserved for migration of OSPFv2 protocol

    extensions.

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 format is displayed and the packet's
 component fields are defined.
 All OSPF packet types (other than the OSPF Hello packets) deal with
 lists of LSAs.  For example, Link State Update packets implement the
 flooding of LSAs throughout the OSPF routing domain.  The format of
 LSAs is described in Section A.4.
 The receive processing of OSPF packets is detailed in Section 4.2.2.
 The sending of OSPF packets is explained in Section 4.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 4.2.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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Version #   |     Type      |         Packet length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Router ID                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Area ID                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Checksum             |  Instance ID  |      0        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        The OSPF Packet Header
 Version #
    The OSPF version number.  This specification documents version 3
    of the OSPF protocol.

Coltun, et al. Standards Track [Page 60] RFC 5340 OSPF for IPv6 July 2008

 Type
    The OSPF packet types are as follows.  See Appendix A.3.2 through
    Appendix 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.
 Area ID
    A 32-bit number identifying the area to which this packet belongs.
    All OSPF packets are associated with a single area.  Most travel a
    single hop only.  Packets traversing a virtual link are labeled
    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 Section 8.1 of [IPV6].  The "Upper-Layer Packet
    Length" in the pseudo-header is set to the 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 link-local significance only.  Received
    packets whose Instance ID is not equal to the receiving
    interface's Instance ID are discarded.

Coltun, et al. Standards Track [Page 61] RFC 5340 OSPF for IPv6 July 2008

 0
    These fields are reserved.  They SHOULD be set to 0 when sending
    protocol packets and MUST be ignored when receiving protocol
    packets.

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 allowing differences to 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 bidirectional
 communication (the Router IDs of all neighbors whose Hellos have been
 recently received).
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      3        |       1       |         Packet Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Router ID                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Area ID                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Checksum             | Instance ID   |     0         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Interface ID                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Rtr Priority  |             Options                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        HelloInterval          |       RouterDeadInterval      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Designated Router ID                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Backup Designated Router ID                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Neighbor ID                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        ...                                    |
                         The OSPF Hello Packet

Coltun, et al. Standards Track [Page 62] RFC 5340 OSPF for IPv6 July 2008

 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
    ([INTFMIB]).
 Rtr Priority
    This router's Router Priority.  Used in (Backup) Designated Router
    election.  If set to 0, the router will be ineligible to become
    (Backup) Designated Router.
 Options
    The optional capabilities supported by the router, as documented
    in Section A.2.
 HelloInterval
    The number of seconds between this router's Hello packets.
 RouterDeadInterval
    The number of seconds before declaring a silent router down.
 Designated Router ID
    The sending router's view of the identity of the Designated Router
    for this network.  The Designated Router is identified by its
    Router ID.  It is set to 0.0.0.0 if there is no Designated Router.
 Backup Designated Router ID
    The sending router's view of the identity of the Backup Designated
    Router for this network.  The Backup Designated Router is
    identified by its IP Router ID.  It is set to 0.0.0.0 if there is
    no Backup Designated Router.
 Neighbor ID
    The Router IDs of each router on the network with neighbor state
    1-Way or greater.

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
 and the other is the slave.  The master sends Database Description
 packets (polls) that 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 63] RFC 5340 OSPF for IPv6 July 2008

     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 OSPF Database Description Packet
 The format of the Database Description packet is very similar to both
 the Link State Request packet and the Link State Acknowledgment
 packet.  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
 [OSPFV2].  The reception of Database Description packets is
 documented in Section 10.6 of [OSPFV2].
 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 [MTUDISC].

Coltun, et al. Standards Track [Page 64] RFC 5340 OSPF for IPv6 July 2008

    Interface MTU should be set to 0 in Database Description packets
    sent over virtual links.
 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 for both the master and slave routers have been
    exchanged.
 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 Appendix A.4.2.
 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 LSA
 instances in response.
 The sending of Link State Request packets is documented in Section
 10.9 of [OSPFV2].  The reception of Link State Request packets is
 documented in Section 10.7 of [OSPFV2].

Coltun, et al. Standards Track [Page 65] RFC 5340 OSPF for IPv6 July 2008

     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                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                 ...                           |
                  The OSPF Link State Request Packet
 Each LSA requested is specified by its LS type, Link State ID, and
 Advertising Router.  This uniquely identifies the LSA without
 specifying its instance.  Link State Request packets are understood
 to be requests for the most recent instance of the specified LSAs.

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

Coltun, et al. Standards Track [Page 66] RFC 5340 OSPF for IPv6 July 2008

     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                               |
    +-                                                            +-+
    |                             ...                               |
                   The OSPF Link State Update Packet
 # 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
 Appendix A.4.2.  Detailed formats of the different types of LSAs are
 described Appendix 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 or
 implicitly acknowledged.  Explicit acknowledgment is accomplished
 through the sending and receiving of Link State Acknowledgment
 packets.  The sending of Link State Acknowledgment packets is
 documented in Section 13.5 of [OSPFV2].  The reception of Link State
 Acknowledgment packets is documented in Section 13.7 of [OSPFV2].
 Multiple LSAs MAY 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 to the multicast
 address AllSPFRouters, the multicast address AllDRouters, or to a
 neighbor's unicast address (see Section 13.5 of [OSPFV2] for
 details).

Coltun, et al. Standards Track [Page 67] RFC 5340 OSPF for IPv6 July 2008

 The format of this packet is similar to that of the Data Description
 packet.  The body of both packets is simply a list of LSA headers.
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      3        |       5       |        Packet Length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Router ID                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Area ID                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Checksum             |  Instance ID  |      0        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +-                                                             -+
    |                                                               |
    +-                        An LSA Header                        -+
    |                                                               |
    +-                                                             -+
    |                                                               |
    +-                                                             -+
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              ...                              |
               The OSPF Link State Acknowledgment Packet
 Each acknowledged LSA is described by its LSA header.  The LSA header
 is documented in Appendix 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 document defines eight distinct types of LSAs.  Each LSA begins
 with a standard 20-byte LSA header.  This header is explained in
 Appendix A.4.2.  Succeeding sections describe each LSA type
 individually.
 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, AS-
 external-LSAs, and NSSA-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

Coltun, et al. Standards Track [Page 68] RFC 5340 OSPF for IPv6 July 2008

 flooding algorithm is reliable, ensuring that all routers common to a
 flooding scope have the same collection of LSAs associated with that
 flooding scope.  (See Section 4.5 for more information concerning the
 flooding algorithm.)  This collection of LSAs is called the link-
 state database.
 From the link-state database, each router constructs a shortest-path
 tree with itself as root.  This yields a routing table (see Section
 11 of [OSPFV2]).  For details on the routing table build process, see
 Section 4.8.

A.4.1. IPv6 Prefix Representation

 IPv6 addresses are bit strings of length 128.  IPv6 routing
 protocols, 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 Appendix A.4.1.1).  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
 Appendix A.4.5, Appendix A.4.7, Appendix A.4.8, Appendix A.4.9, and
 Appendix A.4.10.

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.  For
 example, they can indicate that prefixes are to be ignored in some
 cases or are to be marked as not readvertisable in others.
                   0  1  2  3  4  5  6  7
                  +--+--+--+--+--+-+--+--+
                  |  |  |  |DN| P|x|LA|NU|
                  +--+--+--+--+--+-+--+--+
                        The PrefixOptions Field

Coltun, et al. Standards Track [Page 69] RFC 5340 OSPF for IPv6 July 2008

 NU-bit
    The "no unicast" capability bit.  If set, the prefix should be
    excluded from IPv6 unicast calculations.  If not set, it should be
    included.
 LA-bit
    The "local address" capability bit.  If set, the prefix is
    actually an IPv6 interface address of the Advertising Router.
    Advertisement of local interface addresses is described in
    Section 4.4.3.9.  An implementation MAY also set the LA-bit for
    prefixes advertised with a host PrefixLength (128).
 x-bit
    This bit was previously defined as a "multicast" capability bit.
    However, the use was never adequately specified and has been
    deprecated for OSPFv3.  The bit should be set to 0 and ignored
    when received.  It may be reassigned in the future.
 P-bit
    The "propagate" bit.  Set on NSSA area prefixes that should be
    readvertised by the translating NSSA area border [NSSA].
 DN-bit
    This bit controls an inter-area-prefix-LSAs or AS-external-LSAs
    re-advertisement in a VPN environment as specified in [DN-BIT].

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.

Coltun, et al. Standards Track [Page 70] RFC 5340 OSPF for IPv6 July 2008

     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            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            The LSA Header
 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 Appendix A.4.2.1 for a
    detailed description of LS type.
 Link State ID
    The originating router's identifier for the LSA.  The combination
    of the Link State ID, LS type, and Advertising Router uniquely
    identify 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
    Successive instances of an LSA are given successive LS sequence
    numbers.  The sequence number can be used to detect old or
    duplicate LSA instances.  See Section 12.1.6 in [OSPFV2] 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 [OSPFV2] for more details.

Coltun, et al. Standards Track [Page 71] RFC 5340 OSPF for IPv6 July 2008

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

A.4.2.1. LSA 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          |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                               LSA Type
 The U-bit indicates how the LSA should be handled by a router that
 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 the type is understood
                                 U-Bit
 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 originating link
   0  1    Area Scoping - Flooded only in originating area
   1  0    AS Scoping - Flooded throughout AS
   1  1    Reserved
                            Flooding Scope
 The LSA function codes are defined as follows.  The origination and
 processing of these LSA function codes are defined elsewhere in this
 document, except for the NSSA-LSA (see [NSSA]) and 0x2006, which was
 previously used by MOSPF (see [MOSPF]).  MOSPF has been deprecated
 for OSPFv3.  As shown below, each LSA function b code also implies a
 specific setting for the U, S1, and S2 bits.

Coltun, et al. Standards Track [Page 72] RFC 5340 OSPF for IPv6 July 2008

          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    Deprecated (may be reassigned)
          7                   0x2007    NSSA-LSA
          8                   0x0008    Link-LSA
          9                   0x2009    Intra-Area-Prefix-LSA
                           LSA Function Code

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

Coltun, et al. Standards Track [Page 73] RFC 5340 OSPF for IPv6 July 2008

     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  |Nt|x|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                          |
    +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             ...                                |
                           Router-LSA Format
 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.

Coltun, et al. Standards Track [Page 74] RFC 5340 OSPF for IPv6 July 2008

 Bit V
    When set, the router is an endpoint of one or more fully adjacent
    virtual links having the described area as transit area (V is for
    virtual link endpoint).
 Bit E
    When set, the router is an AS boundary router (E is for external).
 Bit B
    When set, the router is an area border router (B is for border).
 Bit x
    This bit was previously used by MOSPF (see [MOSPF]) and has been
    deprecated for OSPFv3.  The bit should be set to 0 and ignored
    when received.  It may be reassigned in the future.
 Bit Nt
    When set, the router is an NSSA border router that is
    unconditionally translating NSSA-LSAs into AS-external-LSAs (Nt
    stands for NSSA translation).  Note that such routers have their
    NSSATranslatorRole area configuration parameter set to Always.
    (See [NSSA].)
 Options
    The optional capabilities supported by the router, as documented
    in Appendix 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
                            Router Link Types

Coltun, et al. Standards Track [Page 75] RFC 5340 OSPF for IPv6 July 2008

 Metric
    The cost of using this router interface for outbound traffic.
 Interface ID
    The Interface ID assigned to the interface being described.  See
    Section 4.1.2 and Appendix C.3.
 Neighbor Interface ID
    The Interface ID the neighbor router has associated with the link,
    as advertised in the neighbor's Hello packets.  For transit (type
    2) links, the link's Designated Router is the neighbor described.
    For other link types, the sole adjacent neighbor is described.
 Neighbor Router ID
    The Router ID the of the neighbor router.  For transit (type 2)
    links, the link's Designated Router is the neighbor described.
    For other link types, the sole adjacent neighbor is described.
 For transit (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 that includes
 two or more adjacent 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 4.4.3.3.

Coltun, et al. Standards Track [Page 76] RFC 5340 OSPF for IPv6 July 2008

     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                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             ...                               |
                          Network-LSA Format
 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.

A.4.5. Inter-Area-Prefix-LSAs

 Inter-area-prefix-LSAs have LS type equal to 0x2003.  These LSAs are
 the IPv6 equivalent of OSPF for IPv4's type 3 summary-LSAs (see
 Section 12.4.3 of [OSPFV2]).  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 4.4.3.4.
 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.

Coltun, et al. Standards Track [Page 77] RFC 5340 OSPF for IPv6 July 2008

     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                         |
    |                             ...                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Inter-Area-Prefix-LSA Format
 Metric
    The cost of this route.  Expressed in the same units as the
    interface costs in router-LSAs.  When the inter-area-prefix-LSA is
    describing a route to a range of addresses (see Appendix 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
    Appendix A.4.1.

A.4.6. Inter-Area-Router-LSAs

 Inter-area-router-LSAs have LS type equal to 0x2004.  These LSAs are
 the IPv6 equivalent of OSPF for IPv4's type 4 summary-LSAs (see
 Section 12.4.3 of [OSPFV2]).  Originated by area border routers, they
 describe routes to AS boundary routers in other areas.  To see why it
 is necessary to advertise the location of each ASBR, consult Section
 16.4 in [OSPFV2].  Each LSA describes a route to a single router.
 For details concerning the construction of inter-area-router-LSAs,
 see Section 4.4.3.5.

Coltun, et al. Standards Track [Page 78] RFC 5340 OSPF for IPv6 July 2008

     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                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Inter-Area-Router-LSA Format
 Options
    The optional capabilities supported by the router, as documented
    in Appendix A.2.
 Metric
    The cost of this route.  Expressed in the same units as the
    interface costs in router-LSAs.
 Destination Router ID
    The Router ID of the router being described by the LSA.

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

Coltun, et al. Standards Track [Page 79] RFC 5340 OSPF for IPv6 July 2008

     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)             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        AS-external-LSA Format
 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 other LSAs (i.e., the same units
    as the interface costs in router-LSAs).
 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.

Coltun, et al. Standards Track [Page 80] RFC 5340 OSPF for IPv6 July 2008

 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
    Appendix 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.  It MUST
    NOT be set to the IPv6 Unspecified Address (0:0:0:0:0:0:0:0) or an
    IPv6 Link-Local Address (Prefix FE80/10).  While OSPFv3 routes are
    normally installed with link-local addresses, an OSPFv3
    implementation advertising a forwarding address MUST advertise a
    global IPv6 address.  This global IPv6 address may be the next-hop
    gateway for an external prefix or may be obtained through some
    other method (e.g., configuration).
 External Route Tag
    A 32-bit field that MAY be used to communicate additional
    information between AS boundary routers.  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.
 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).  When present, Forwarding Address
 always comes first, External Route Tag next, and the Referenced Link
 State ID last.

Coltun, et al. Standards Track [Page 81] RFC 5340 OSPF for IPv6 July 2008

A.4.8. NSSA-LSAs

 NSSA-LSAs have LS type equal to 0x2007.  These LSAs are originated by
 AS boundary routers within an NSSA and describe destinations external
 to the AS that may or may not be propagated outside the NSSA (refer
 to [NSSA]).  Other than the LS type, their format is exactly the same
 as AS-external LSAs as described in Appendix A.4.7.
 A global IPv6 address MUST be selected as forwarding address for
 NSSA-LSAs that are to be propagated by NSSA area border routers.  The
 selection should proceed the same as OSPFv2 NSSA support [NSSA] with
 additional checking to ensure IPv6 link-local address are not
 selected.

A.4.9. Link-LSAs

 Link-LSAs have LS type equal to 0x0008.  A router originates a
 separate link-LSA for each attached physical link.  These LSAs have
 link-local flooding scope; they are never flooded beyond the
 associated link.  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.
 3.  They allow the router to advertise a collection of Options bits
     in the network-LSA originated by the Designated Router on a
     broadcast or NBMA link.
 For details concerning the construction of links-LSAs, see
 Section 4.4.3.8.
 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 82] RFC 5340 OSPF for IPv6 July 2008

     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 Priority  |                Options                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +-                                                             -+
    |                                                               |
    +-                Link-local Interface Address                 -+
    |                                                               |
    +-                                                             -+
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         # prefixes                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  PrefixLength | PrefixOptions |             0                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Address Prefix                         |
    |                             ...                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             ...                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  PrefixLength | PrefixOptions |             0                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Address Prefix                         |
    |                             ...                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            Link-LSA Format
 Rtr Priority
    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 by the Designated Router on
    broadcast or NBMA links.

Coltun, et al. Standards Track [Page 83] RFC 5340 OSPF for IPv6 July 2008

 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
    Appendix A.4.1.

A.4.10. 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 local router address, an attached stub
 network segment, or an attached transit network segment.  In IPv4,
 the first two were accomplished via the router's router-LSA and the
 last via a network-LSA.  In OSPF for IPv6, all addressing information
 that was advertised in router-LSAs and network-LSAs has been removed
 and is now advertised in intra-area-prefix-LSAs.  For details
 concerning the construction of intra-area-prefix-LSA, see
 Section 4.4.3.9.
 A router can originate multiple intra-area-prefix-LSAs for each
 router or transit network.  Each such LSA is distinguished by its
 unique Link State ID.

Coltun, et al. Standards Track [Page 84] RFC 5340 OSPF for IPv6 July 2008

     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                          |
    |                             ...                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Intra-Area-Prefix LSA Format
 # prefixes
    The number of IPv6 address prefixes contained in the LSA.
 Referenced LS Type, Referenced Link State ID, and Referenced
    Advertising Router
    Identifies the router-LSA or network-LSA with which the IPv6
    address prefixes should be associated.  If Referenced LS Type is
    0x2001, 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 0x2002, 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 85] RFC 5340 OSPF for IPv6 July 2008

 The rest of the intra-area-prefix-LSA contains a list of IPv6
 prefixes to be associated with the router or transit link, as well as
 their associated costs.
 PrefixLength, PrefixOptions, and Address Prefix
    Representation of an IPv6 address prefix, as described in
    Appendix A.4.1.
 Metric
    The cost of this prefix.  Expressed in the same units as the
    interface costs in router-LSAs.

Appendix B. Architectural Constants

 Architectural constants for the OSPF protocol are defined in Appendix
 B of [OSPFV2].  The only difference for OSPF for IPv6 is that
 DefaultDestination is encoded as a prefix with length 0 (see
 Appendix A.4.1).

Appendix 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.  Similarly, 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.

Coltun, et al. Standards Track [Page 86] RFC 5340 OSPF for IPv6 July 2008

 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 due to a Router ID change, the
    router should flush its self-originated LSAs from the routing
    domain (see Section 14.1 of [OSPFV2]).  Otherwise, they will
    persist for up to MaxAge seconds.
 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 both routing protocol information 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 87] RFC 5340 OSPF for IPv6 July 2008

 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 area or NSSA.  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 or NSSA area.  Also,
    virtual links cannot be configured through stub or NSSA areas.
    For more information, see Section 3.6 of [OSPFV2] and [NSSA].
 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
    [OSPFV2] for more information.
 NSSATranslatorRole and TranslatorStabilityInterval
    These area parameters are described in Appendix D of [NSSA].
    Additionally, an NSSA Area Border Router (ABR) is also required to
    allow configuration of whether or not an NSSA default route is
    advertised in an NSSA-LSA.  If advertised, its metric and metric
    type are configurable.  These requirements are also described in
    Appendix D of [NSSA].
 ImportSummaries
    When set to enabled, prefixes external to the area are imported
    into the area via the advertisement of inter-area-prefix-LSAs.
    When set to disabled, inter-area routes are not imported into the
    area.  The default setting is enabled.  This parameter is only
    valid for stub or NSSA areas.

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.  Therefore, these parameters 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.

Coltun, et al. Standards Track [Page 88] RFC 5340 OSPF for IPv6 July 2008

 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
    ([INTFMIB]).
 IPv6 prefixes
    The list of IPv6 prefixes to associate with the link.  These will
    be advertised in intra-area-prefix-LSAs.
 Interface output cost(s)
    The cost of sending a packet on the interface, expressed in the
    link-state metric.  This is advertised as the link cost for this
    interface in the router's router-LSA.  The interface output cost
    MUST always be greater than 0.
 RxmtInterval
    The number of seconds between LSA retransmissions for adjacencies
    belonging to this interface.  Also used when retransmitting
    Database Description and Link State Request packets.  This should
    be well over the expected round-trip delay between any two routers
    on the attached link.  The setting of this value should be
    conservative or needless retransmissions will result.  Sample
    value for a local area network: 5 seconds.
 InfTransDelay
    The estimated number of seconds it takes to transmit a Link State
    Update packet over this interface.  LSAs contained in the update
    packet must have their age incremented by this amount before
    transmission.  This value should take into account the
    transmission and propagation delays of the interface.  It MUST be
    greater than 0.  Sample value for a local area network: 1 second.
 Router Priority
    An 8-bit unsigned integer.  When two routers attached to a network
    both attempt to become the 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
    the Designated Router on the attached link.  Router Priority is
    only configured for interfaces to broadcast and NBMA networks.

Coltun, et al. Standards Track [Page 89] RFC 5340 OSPF for IPv6 July 2008

 HelloInterval
    The length of time, in seconds, between Hello packets that the
    router sends on the interface.  This value is advertised in the
    router's Hello packets.  It MUST be the same for all routers
    attached to a common link.  The smaller the HelloInterval, the
    faster topological changes will be detected.  However, more OSPF
    routing protocol traffic will ensue.  Sample value for a X.25 PDN:
    30 seconds.  Sample value for a local area network (LAN): 10
    seconds.
 RouterDeadInterval
    After ceasing to hear a router's Hello packets, the number of
    seconds before its neighbors declare the router down.  This is
    also advertised in the router's Hello packets in their
    RouterDeadInterval field.  This should be some multiple of the
    HelloInterval (e.g., 4).  This value again MUST be the same for
    all routers attached to a common link.
 LinkLSASuppression
    Indicates whether or not origination of a link-LSA is suppressed.
    If set to "enabled" and the interface type is not broadcast or
    NBMA, the router will not originate a link-LSA for the link.  This
    implies that other routers on the link will ascertain the router's
    next-hop address using a mechanism other than the link-LSA (see
    Section 4.8.2).  The default value is "disabled" for interface
    types described in this specification.  It is implicitly
    "disabled" if the interface type is broadcast or NBMA.  Future
    interface types MAY specify a different default.

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 a point-to-point link with no global IPv6
 addresses 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
 Appendix C.3).  Virtual links do not have link-local addresses, but
 instead use one of the router's global-scope IPv6 addresses as the IP
 source in OSPF protocol packets it sends on 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 transit area intra-area path between the two endpoint routers.
 The parameter RxmtInterval may be configured and should be well over

Coltun, et al. Standards Track [Page 90] RFC 5340 OSPF for IPv6 July 2008

 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 long.
 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 that the virtual link traverses (referred to
 as the virtual link's transit area).  Virtual links cannot be
 configured through stub or NSSA areas.  Additionally, an Instance ID
 may be configured for virtual links from different protocol instances
 in order to utilize the same transit area (without requiring
 different Router IDs for demultiplexing).

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 listing 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 the Designated Router
 (i.e., those routers whose Router Priority for the network is non-
 zero), and then only if no automatic procedure for discovering
 neighbors exists:
 List of all other attached routers
    The list of all other routers attached to the NBMA network.  Each
    router is configured with its Router ID and IPv6 link-local
    address on the network.  Also, for each router listed, that
    router's eligibility to become the Designated Router must be
    defined.  When an interface to an NBMA network first comes up, the
    router only sends Hello packets to those neighbors eligible to
    become the Designated Router until such time that a Designated
    Router is elected.
 PollInterval
    If a neighboring router has become inactive (Hello packets have
    not been seen for RouterDeadInterval seconds), it may still be
    necessary to send Hello packets to the dead neighbor.  These Hello
    packets will be sent at the reduced rate PollInterval, which
    should be much larger than HelloInterval.  Sample value for a PDN
    X.25 network: 2 minutes.

Coltun, et al. Standards Track [Page 91] RFC 5340 OSPF for IPv6 July 2008

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

C.7. Host Route Parameters

 Host prefixes are advertised in intra-area-prefix-LSAs.  They
 indicate either local 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
    An IPv6 prefix belonging to the directly connected host.  This
    must not be a valid IPv6 global prefix.
 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 92] RFC 5340 OSPF for IPv6 July 2008

Authors' Addresses

 Rob Coltun
 Acoustra Productions
 3204 Brooklawn Terrace
 Chevy Chase, MD  20815
 USA
 Dennis Ferguson
 Juniper Networks
 1194 N. Mathilda Avenue
 Sunnyvale, CA  94089
 USA
 EMail: dennis@juniper.net
 John Moy
 Sycamore Networks, Inc
 10 Elizabeth Drive
 Chelmsford, MA  01824
 USA
 EMail: jmoy@sycamorenet.com
 Acee Lindem (editor)
 Redback Networks
 102 Carric Bend Court
 Cary, NC  27519
 USA
 EMail: acee@redback.com

Coltun, et al. Standards Track [Page 93] RFC 5340 OSPF for IPv6 July 2008

Full Copyright Statement

 Copyright (C) The IETF Trust (2008).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Coltun, et al. Standards Track [Page 94]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5340.txt · Last modified: 2008/07/22 18:54 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki