One document matched: draft-ietf-ospf-ospfv3-update-21.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocdepth="4" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc category="std" obsoletes="2740" ipr="full3978"
docName="draft-ietf-ospf-ospfv3-update-21.txt">
<front>
<title>OSPF for IPv6</title>
<author initials='R' surname="Coltun" fullname='Rob Coltun'>
<organization>Acoustra Productions</organization>
<address>
<postal>
<street>3204 Brooklawn Terrace</street>
<city>Chevy Chase</city> <region>MD</region>
<country>USA</country>
<code>20815</code>
</postal>
<email>undisclosed</email>
</address>
</author>
<author initials='D' surname="Ferguson" fullname='Dennis Ferguson'>
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N. Mathilda Avenue</street>
<city>Sunnyvale</city> <region>CA</region>
<country>USA</country>
<code>94089</code>
</postal>
<email>dennis@juniper.net</email>
</address>
</author>
<author initials='J' surname="Moy" fullname='John Moy'>
<organization>Sycamore Networks, Inc</organization>
<address>
<postal>
<street>10 Elizabeth Drive</street>
<city>Chelmsford</city> <region>MA</region>
<country>USA</country>
<code>01824</code>
</postal>
<email>jmoy@sycamorenet.com</email>
</address>
</author>
<author initials='A.' surname="Lindem (Editor)" fullname='Acee Lindem'>
<organization>Redback Networks</organization>
<address>
<postal>
<street>102 Carric Bend Court</street>
<city>Cary</city> <region>NC</region>
<country>USA</country>
<code>27519</code>
</postal>
<email>acee@redback.com</email>
</address>
</author>
<date month="April" year="2008"/>
<abstract>
<t>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).</t>
<t>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).</t>
<t>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.</t>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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).</t>
<t>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 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.</t>
<section title="Requirements notation">
<t>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 <xref target="RFC-KEYWORDS"/>.</t>
</section>
<section title="Terminology">
<t>This document attempts to use terms from both the OSPF for IPv4
specification (<xref target="OSPFV2"/>) and the IPv6 protocol specifications
(<xref target="IPV6" />). This has produced a mixed result. Most of the terms used
both by OSPF and IPv6 have roughly the same meaning (e.g.,
interfaces). However, there are a few conflicts. IPv6 uses "link"
similarly to IPv4 OSPF's "subnet" or "network". In this case, we have
chosen to use IPv6's "link" terminology. "Link" replaces OSPF's
"subnet" and "network" in most places in this document, although
OSPF's network-LSA remains unchanged (and possibly unfortunately, a
new link-LSA has also been created).</t>
<t>The names of some of the OSPF LSAs have also changed. See
<xref target="lsa-format"/> for details.</t>
<t>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).</t>
</section>
</section>
<section title="Differences from OSPF for IPv4">
<t>Most of the algorithms from OSPF for IPv4 <xref target="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.</t>
<t>The following subsections describe the differences between this
document and <xref target="OSPFV2"/>.</t>
<section title="Protocol processing per-link, not per-subnet">
<t>IPv6 uses the term "link" to indicate "a communication facility or
medium over which nodes can communicate at the link layer" (<xref target="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).</t>
<t>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 (<xref target="OSPFV2"/>) should generally be replaced by
link. Likewise, an OSPF interface now connects to a link instead of
an IP subnet.</t>
<t>This change affects the receiving of OSPF protocol packets, the
contents of Hello packets, and the contents of network-LSAs.</t>
</section>
<section title="Removal of addressing semantics">
<t>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:
<vspace blankLines="1" /><list style="symbols">
<t>IPv6 Addresses are not present in OSPF packets, except in
LSA payloads carried by the Link State Update packets. See
<xref target="packet-format"/> for details.</t>
<t>Router-LSAs and network-LSAs no longer contain network
addresses, but simply express topology information. See
<xref target="lsa-format"/> for details.</t>
<t>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.</t>
<t>Neighboring routers are now always identified by Router ID.
Previously, they had been identified by IPv4 address on
broadcast, NBMA, and point-to-multipoint links.</t>
</list></t>
</section>
<section anchor="flood-scope" title="Addition of Flooding scope">
<t>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:
<vspace blankLines="1" /><list style="symbols">
<t>Link-local scope. LSA is only flooded on the local link and
no further. Used for the new link-LSA. See
<xref target="link-lsa"/> for details.</t>
<t>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.</t>
<t>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.</t>
</list></t>
</section>
<section anchor="multi-intf-instance"
title="Explicit support for multiple instances per link">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="ll-addr" title="Use of link-local addresses">
<t>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 <xref target="IP6ADDR" />.
Link-local unicast addresses are assigned from the IPv6 address range
FE80/10.</t>
<t>OSPF for IPv6 assumes that each router has been assigned link-local
unicast addresses on each of the router's attached
physical links <xref target="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.</t>
<t>On virtual links, a global scope IPv6 address MUST be
used as the source address for OSPF protocol packets.</t>
<t>Link-local addresses appear in OSPF link-LSAs (see
<xref target="link-lsa"/>).
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 (<xref target="inter-area-prefix-lsa"/>),
AS-external-LSAs (<xref target="external-lsa"/>),
NSSA-LSAs (<xref target="nssa-lsa"/>), or intra-area-prefix-LSAs
(<xref target="intra-area-prefix-lsa"/>).</t>
</section>
<section anchor="auth-changes" title="Authentication changes">
<t>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.</t>
<t>When running over IPv6, OSPF relies on the IP Authentication Header
(see <xref target="IPAUTH" />) and the
IP Encapsulating Security Payload (see <xref target="IPESP"/>)
as described in <xref target="OSPFV3-AUTH"/>
to ensure integrity and authentication/confidentiality of routing
exchanges.</t>
<t>Protection of OSPF packet exchanges against accidental data
corruption is provided by the standard IPv6 16-bit one's complement
checksum, covering the entire OSPF packet and prepended IPv6 pseudo-
header (see <xref target="packet-header"/>).</t>
</section>
<section anchor="packet-format" title="Packet format changes">
<t>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.</t>
<t>In detail, changes in OSPF packet format consist of the following:
<vspace blankLines="1" /><list style="symbols">
<t>The OSPF version number has been incremented from 2 to 3.</t>
<t>The Options field in Hello packets and Database Description packets
has been expanded to 24-bits.</t>
<t>The Authentication and AuType fields have been removed from the
OSPF packet header (see <xref target="auth-changes"/>)</t>
<t>The Hello packet now contains no address information at all Rather, it
now includes an Interface ID which the originating router has assigned
to uniquely identify (among its own interfaces) its interface to
the link. This Interface ID will be used as the network-LSA's
Link State ID if the router becomes Designated-Router on the link.</t>
<t>Two option bits, the "R-bit" and the "V6-bit", have been added to
the Options field for processing router-LSAs during the SPF
calculation (see <xref target="options-field"/>).
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.</t>
<t>The OSPF packet header now includes an "Instance ID" which allows
multiple OSPF protocol instances to be run on a single link (see
<xref target="multi-intf-instance"/>).</t>
</list></t>
</section>
<section anchor="lsa-format" title="LSA format changes">
<t>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.</t>
<t>In detail, changes in LSA format consist of the following:
<vspace blankLines="1" /><list style="symbols">
<t>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
<xref target="options-field"/> for details.</t>
<t>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
<xref target="unknown-types"/>).</t>
<t>Addresses in LSAs are now expressed as [prefix, prefix length]
instead of [address, mask] (see
<xref target="prefix-rep"/>). The default route
is expressed as a prefix with length 0.</t>
<t>Router-LSAs and network-LSAs now have no address information and
are network protocol independent.</t>
<t>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.</t>
<t>A new LSA called the link-LSA has been introduced. Link-LSAs have
local-link 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 <xref target="link-lsa"/> for details.</t>
<t>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 <xref target="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 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).</t>
<t>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.</t>
<t>Type-3 summary-LSAs have been renamed "inter-area-prefix-LSAs".
Type-4 summary LSAs have been renamed "inter-area-router-LSAs".</t>
<t>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</t>
<t>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.</t>
<t>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
<xref target="intra-area-prefix-lsa"/> for details.</t>
<t>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.</t>
</list></t>
</section>
<section anchor="unknown-types" title="Handling unknown LSA types">
<t>Handling of unknown LSA types has been made more flexible so that,
based on LS type, unknown LSA types are either treated as having
link-local flooding scope, or are stored and flooded as if they were
understood. This behavior is explicitly coded in the
LSA Handling bit of the link state header's LS type field (see
the U-bit in <xref target="lsa-type"/>).</t>
<t>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.</t>
</section>
<section anchor="stub-nssa-support" title="Stub/NSSA area support">
<t>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.</t>
<t>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.</t>
</section>
<section title="Identifying neighbors by Router ID">
<t>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.</t>
<t>This change affects the reception of OSPF packets (see Section 8.2 of
<xref target="OSPFV2"/>), the lookup of neighbors (Section 10 of <xref target="OSPFV2"/>) and the
reception of Hello packets (Section 10.5 of <xref target="OSPFV2"/>).</t>
<t>The Router ID of 0.0.0.0 is reserved and SHOULD NOT be used.</t>
</section>
</section>
<section title="Implementation details">
<t>When going from IPv4 to IPv6, the basic OSPF mechanisms remain
unchanged from those documented in <xref target="OSPFV2"/>. These mechanisms are
briefly outlined in Section 4 of <xref target="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, along with the basic
ideas behind inter-area routing, importing external information in
AS-external-LSAs, and the various routing calculations are also the
same.</t>
<t>In particular, the following IPv4 OSPF functionality described in
<xref target="OSPFV2"/> remains completely unchanged for IPv6:
<vspace blankLines="1" /><list style="symbols">
<t>Both IPv4 and IPv6 use OSPF packet types described in Section 4.3
of <xref target="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.</t>
<t>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.</t>
<t>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 <xref target="OSPFV2"/>.</t>
<t>The link types (or equivalently, interface types) supported by
OSPF remain unchanged, namely: point-to-point, broadcast, NBMA,
Point-to-Multipoint, and virtual links.</t>
<t>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 <xref target="OSPFV2"/>.</t>
<t>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 <xref target="OSPFV2"/>.</t>
<t>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 <xref target="OSPFV2"/>.</t>
</list></t>
<t>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 <xref target="OSPFV2"/>.</t>
<t>The following subsections provide a recipe for turning an IPv4 OSPF
implementation into an IPv6 OSPF implementation.</t>
<section anchor="data-struct" title="Protocol data structures">
<t>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 <xref target="OSPFV2"/>, with the following modifications:
<vspace blankLines="1" /><list style="symbols">
<t>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
type, U-bit set to 1 (flood even when unrecognized), and AS
flooding scope also appear in the top-level data structure.</t>
</list></t>
<section anchor="area-data-struct" title="The Area Data structure">
<t>The IPv6 area data structure contains all elements defined for IPv4
areas in Section 6 of <xref target="OSPFV2"/>. In addition, all LSAs of known type
which have area flooding scope are contained in the IPv6 area data
structure. This always includes the following LSA types: router-LSAs,
network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, and
intra-area-prefix-LSAs. LSAs with unknown LS type, U-bit set to 1
(flood even when unrecognized) and area scope also appear in the area
data structure. NSSA-LSAs are also
included in an NSSA area's data structure.</t>
</section>
<section anchor="intf-data-struct" title="The Interface Data structure">
<t>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 <xref target="OSPFV2"/>) as follows:
<vspace blankLines="1" /><list style="hanging">
<t hangText="Interface ID"><vspace blankLines="0" />
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 (<xref target="INTFMIB"/>)
as Interface ID. The Interface ID appears in Hello packets sent out
the interface, the link-local-LSA originated by router for the
attached link, and the router-LSA originated by the router-LSA for
the associated area. It will also serve as the Link State ID for
the network-LSA that the router will originate for the link if the
router is elected Designated Router.
<vspace blankLines="0" />
The interface ID for a virtual link is independent of the
interface ID of the outgoing interface it traverses in the transit
area.</t>
<t hangText="Instance ID"><vspace blankLines="0" />
Every interface is assigned an Instance ID. This should default to
0. It is only necessary to assign differently on those links that
will contain multiple separate communities of OSPF Routers. For
example, suppose that there are two communities of routers on a
given ethernet segment that you wish to keep separate.
<vspace blankLines="0" />
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
<xref target="packet-processing"/>)
will then keep the two communities separate.</t>
<t hangText="List of LSAs with link-local scope"><vspace blankLines="0" />
All LSAs with link-local scope and which 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.</t>
<t hangText="IP interface address"><vspace blankLines="0" />
For IPv6, the IPv6 address appearing in the source of OSPF packets
sent out the interface is almost always a link-local address. The
one exception is for virtual links which MUST use one of the
router's own global IPv6 addresses as IP interface
address.</t>
<t hangText="List of link prefixes"><vspace blankLines="0" />
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.</t>
</list></t>
<t>In OSPF for IPv6, each router interface has a single metric
representing the cost of sending packets out the interface. In
addition, OSPF for IPv6 relies on the IP Authentication Header (see
<xref target="IPAUTH" />) and the
IP Encapsulating Security Payload (see <xref target="IPESP"/>) as
described in <xref target="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.</t>
<t>Interface states, events, and the interface state machine remain
unchanged from IPv4 as documented in Sections 9.1, 9.2, and 9.3
of <xref target="OSPFV2"/> respectively. The Designated Router and Backup Designated
Router election algorithm also remains unchanged from the IPv4
election in Section 9.4 of <xref target="OSPFV2"/>.</t>
</section>
<section title="The Neighbor Data Structure">
<t>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 <xref target="OSPFV2"/> are:
<vspace blankLines="1" /><list style="hanging">
<t hangText="Neighbor's Interface ID"><vspace blankLines="0" />
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 Designated Router.</t>
<t hangText="Neighbor IP address"><vspace blankLines="0" />
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.</t>
<t hangText="Neighbor's Designated Router"><vspace blankLines="0" />
The neighbor's choice of Designated Router is now encoded as a
Router ID instead of as an IP address.</t>
<t hangText="Neighbor's Backup Designated Router"><vspace blankLines="0" />
The neighbor's choice of Backup Designated Router is now encoded
as a Router ID instead of as an IP address.</t>
</list></t>
<t>Neighbor states, events, and the neighbor state machine remain
unchanged from IPv4 as documented in Sections 10.1, 10.2, and
10.3 of <xref target="OSPFV2"/> respectively. The decision as to which adjacencies to
form also remains unchanged from the IPv4 logic documented in Section
10.4 of <xref target="OSPFV2"/>.</t>
</section>
</section>
<section anchor="packet-processing" title="Protocol Packet Processing">
<t>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.</t>
<t>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.</t>
<section anchor="proto-send" title="Sending protocol packets">
<t>When an IPv6 router sends an OSPF routing protocol packet, it fills
in the fields of the standard OSPF for IPv6 packet header (see
<xref target="packet-header"/>) as follows:
<vspace blankLines="1" /><list style="hanging">
<t hangText="Version #"><vspace blankLines="0" />
Set to 3, the version number of the protocol as documented in this
specification.</t>
<t hangText="Type"><vspace blankLines="0" />
The type of OSPF packet, such as Link State Update or Hello
packet.</t>
<t hangText="Packet length"><vspace blankLines="0" />
The length of the entire OSPF packet in bytes, including the
standard OSPF packet header.</t>
<t hangText="Router ID"><vspace blankLines="0" />
The identity of the router itself (who is originating the packet).</t>
<t hangText="Area ID"><vspace blankLines="0" />
The OSPF area for the interface that the packet is being sent on.</t>
<t hangText="Instance ID"><vspace blankLines="0" />
The OSPF Instance ID associated with the interface that the packet
is being sent out of.</t>
<t hangText="Checksum"><vspace blankLines="0" />
The standard IPv6 16-bit one's complement checksum, covering the
entire OSPF packet and prepended IPv6 pseudo-header (see
<xref target="packet-header"/>).</t>
</list></t>
<t>Selection of OSPF routing protocol packets' IPv6 source and
destination addresses is performed identically to the IPv4 logic in
Section 8.1 of <xref target="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).</t>
<t>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 <xref target="OSPFV2"/> respectively. Sending
Hello packets is documented in Section 3.2.1.1, and the sending of
Database Description packets in Section 3.2.1.2. The sending of Link
State Update packets is documented in Section 3.5.2.</t>
<section title="Sending Hello Packets">
<t>IPv6 changes the way OSPF Hello packets are sent in the following
ways (compare to Section 9.5 of <xref target="OSPFV2"/>):
<vspace blankLines="1" /><list style="symbols">
<t>Before the Hello packet is sent out an interface, the interface's
Interface ID MUST be copied into the Hello packet.</t>
<t>The Hello packet no longer contains an IP network mask since OSPF
for IPv6 runs per-link instead of per-subnet.</t>
<t>The choice of Designated Router and Backup Designated Router are
now indicated within Hellos by their Router IDs instead of by
their IP interface addresses. Advertising the Designated
Router (or Backup Designated Router) as 0.0.0.0 indicates that the
Designated Router (or Backup Designated Router) has not yet been
chosen.</t>
<t>The Options field within Hello packets has moved around, getting
larger in the process. More options bits are now possible. Those
that MUST be set correctly in Hello packets are: The E-bit is set
if and only if the interface attaches to a 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 <xref target="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 <xref target="DEMAND" />). Unrecognized bits in the Hello packet's Options
field should be cleared.</t>
</list></t>
<t>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 <xref target="OSPFV2"/>.</t>
</section>
<section title="Sending Database Description Packets">
<t>The sending of Database Description packets differs from Section 10.8
of <xref target="OSPFV2"/> in the following ways:
<vspace blankLines="1" /><list style="symbols">
<t>The Options field within Database Description packets has moved
around, getting larger in the process. More options bits are now
possible. Those that MUST be set correctly in Database Description
packets are: The DC-bit is set if and only if the
router wishes to suppress the sending of Hellos over the interface
(see <xref target="DEMAND" />). Unrecognized bits in the Database Description
packet's Options field should be cleared.</t>
</list></t>
</section>
</section>
<section anchor="proto-receive" title="Receiving Protocol Packets">
<t>Whenever a router receives an OSPF protocol packet it is
marked with the interface it was received on. For routers that have
virtual links configured, it may not be immediately obvious which
interface to associate the packet with. For example, consider the
Router RT11 depicted in Figure 6 of <xref target="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.</t>
<t>In order for the packet to be passed to OSPF for processing, the
following tests must be performed on the encapsulating IPv6 headers:
<vspace blankLines="1" /><list style="symbols">
<t>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).</t>
<t>The Next Header field of the immediately encapsulating IPv6 header
MUST specify the OSPF protocol (89).</t>
<t>Any encapsulating IP Authentication Headers (see <xref target="IPAUTH" />) and the
IP Encapsulating Security Payloads (see <xref target="IPESP"/>)
MUST be processed and/or verified to ensure integrity and
authentication/confidentiality of OSPF routing exchanges. This is
described in <xref target="OSPFV3-AUTH"/>.</t>
</list></t>
<t>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:
<vspace blankLines="1" /><list style="symbols">
<t>The version number field MUST specify protocol version 3.</t>
<t>The standard IPv6 16-bit one's complement checksum, covering the
entire OSPF packet and prepended IPv6 pseudo-header, must be
verified (see <xref target="packet-header"/>).</t>
<t>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:
<vspace blankLines="1" /><list style="numbers">
<t>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.</t>
<t>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 which
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).</t>
</list></t>
<t>Locally originated packets SHOULD NOT be processed by OSPF except
for support of multiple interfaces attached to the same link
as described in <xref target="multi-intf"/>. Locally
originated packets have a source address
equal to one of the router's local addresses.</t>
<t>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 <xref target="OSPFV2"/>).</t>
</list></t>
<t>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.</t>
<t>If the packet type is Hello, it should then be further processed by
the Hello packet processing as described in <xref target="hello-receive"/>.
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.</t>
<t>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 <xref target="OSPFV2"/> respectively with the exceptions noted below.
<vspace blankLines="1" /><list style="symbols">
<t>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 <xref target="OSPFV2"/>,
these would result in the adjacency being brought down with a
SequenceMismatch event.</t>
</list></t>
<t>The receiving of Hello packets is
documented in <xref target="hello-receive"/> and the receiving
of Link State Update packets is documented in
<xref target="receive-lsu"/>.</t>
<section anchor="hello-receive" title="Receiving Hello Packets">
<t>The receive processing of Hello packets differs from Section 10.5 of
<xref target="OSPFV2"/> in the following ways:
<vspace blankLines="1" /><list style="symbols">
<t>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.</t>
<t>There is no longer a Network Mask field in the Hello packet.</t>
<t>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.</t>
</list></t>
</section>
</section>
</section>
<section anchor="route-table" title="The Routing table Structure">
<t>The routing table used by OSPF for IPv4 is defined in Section 11 of
<xref target="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
<xref target="spf"/>).</t>
<t>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:
<vspace blankLines="1" /><list style="symbols">
<t>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.</t>
<t>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.</t>
</list></t>
<t>The fields in the IPv4 OSPF routing table (see Section 11 of <xref target="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 router.</t>
<t>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
<xref target="intra-area-prefix-lsa-format"/>).</t>
<section title="Routing table lookup">
<t>Routing table lookup (i.e., determining the best matching routing
table entry during IP forwarding) is the same for IPv6 as for IPv4.</t>
</section>
</section>
<section title="Link State Advertisements">
<t>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 <xref target="OSPFV2"/>, and is not encoded within OSPF for
IPv6's LSAs.</t>
<t>These changes will be described in detail in the following
subsections.</t>
<section title="The LSA Header">
<t>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
<xref target="OSPFV2"/> respectively. However, the following fields have changed for
IPv6:
<vspace blankLines="1" /><list style="hanging">
<t hangText="Options"><vspace blankLines="0" />
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 <xref target="options-field"/>).
Additionally, a separate PrefixOptions
field, 8 bits in length, is attached to each prefix advertised
within the body of an LSA.</t>
<t hangText="LS type"><vspace blankLines="0" />
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
<xref target="lsa-type"/>
for the current coding of the LS type field.</t>
<t hangText="Link State ID"><vspace blankLines="0" />
Link State ID remains at 32 bits in length. However, except for
network-LSAs and link-LSAs, Link State ID has shed any addressing
semantics. For example, an IPv6 router originating multiple
AS-external-LSAs could start by assigning the first a Link State ID
of 0.0.0.1, the second a Link State ID of 0.0.0.2, and so on.
Instead of the IPv4 behavior of encoding the network number within
the AS-external-LSA's Link State ID, the IPv6 Link State ID simply
serves as a way to differentiate multiple LSAs originated by the
same router.<vspace blankLines="0" />
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.</t>
</list></t>
</section>
<section title="The link-state database">
<t>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 <xref target="OSPFV2"/>).</t>
<t>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 <xref target="data-struct"/>)
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 <xref target="area-data-struct"/>) 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 unknown LS type and U-bit set to 0
and/or link-local flooding scope are contained within the appropriate
interface structure (see <xref target="intf-data-struct"/>);
this includes link-LSAs.</t>
<t>To lookup 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.</t>
</section>
<section anchor="Orig-LSAs" title="Originating LSAs">
<t>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.</t>
<t>The list of events causing LSAs to be reoriginated for IPv4
is given in Section 12.4 of <xref target="OSPFV2"/>. The following events and/or
actions are added for IPv6:
<vspace blankLines="1" /><list style="symbols">
<t>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
Designated Router, the router may also need to (re)originate and/or flush the
network LSA corresponding to the interface.</t>
<t>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.</t>
<t>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.</t>
<t>The Interface ID of a neighbor changes. This may cause a new
instance of a router-LSA to be originated for the associated
area.</t>
<t>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.</t>
<t>A new link-LSA is received, causing the link's collection of
prefixes to change. If the router is Designated Router for the
link, it originates a new intra-area-prefix-LSA.</t>
<t>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 Designated Router for the
link, it originates a new network-LSA.</t>
</list></t>
<t>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 <xref target="OSPFV2"/> has been reworked to
show IPv6 addressing, resulting in Figure 1. The OSPF cost of each
interface is has been displayed in Figure 1. The assignment of IPv6
prefixes to network links is shown in Table 1. A single area address
range has been configured for Area 1, so that outside of Area 1 all
of its prefixes are covered by a single route to 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.
<vspace blankLines="100" />
<figure title="Figure 1">
<artwork>
..........................................
. 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
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
</artwork>
</figure></t>
<section anchor="lsa-options" title="LSA Options">
<t>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 <xref target="DEMAND" />). All unrecognized bits in the Options
field should be cleared.</t>
<t>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.</t>
</section>
<section anchor="router-lsa" title="Router-LSAs">
<t>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.</t>
<t>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 <xref target="OSPFV2"/>.</t>
<t>Each of the router's interfaces to the area are then described by
appending "link descriptions" to the router-LSA. Each link
description is 16 bytes long, consisting of 5 fields: (link) Type,
Metric, Interface ID, Neighbor Interface ID, and Neighbor Router ID
(see <xref target="router-lsa-format"/>). Interfaces in state
"Down" or "Loopback" are not
described (although looped back interfaces can contribute prefixes to
intra-area-prefix-LSAs). Nor are interfaces without any full
adjacencies described (except in the case of multiple standby interfaces
as described in <xref target="multi-intf"/>). 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.
<vspace blankLines="1" /><list style="hanging">
<t hangText="Point-to-point interfaces"><vspace blankLines="0" />
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.</t>
<t hangText="Broadcast and NBMA interfaces"><vspace blankLines="0" />
If the router is fully adjacent to the link's Designated Router
or if the router itself is Designated Router and is fully adjacent
to at least one other router, add a single Type 2 link description
(transit network). The Neighbor Interface ID field is set to the
Interface ID advertised by the Designated Router in its Hello
packets and the Neighbor Router ID field is set to the Designated
Router's Router ID.</t>
<t hangText="Virtual links"><vspace blankLines="0" />
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 <xref target="virtual-link"/>).</t>
<t hangText="Point-to-Multipoint interfaces"><vspace blankLines="0" />
For each fully adjacent neighbor associated with the interface,
add a separate Type 1 link description (point-to-point) with
Neighbor Interface ID field set to the Interface ID advertised by
the neighbor in its Hello packets and Neighbor Router ID field
set to the neighbor's Router ID.</t>
</list></t>
<t>As an example, consider the router-LSA that router RT3 would
originate for Area 1 in Figure 1. Only a single interface must be
described, namely that which connects to the transit network N3. It
assumes that RT4 has been elected Designated Router of Network N3.
<figure title="RT3's router-LSA for Area 1">
<artwork>
; 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
</artwork>
</figure></t>
<t>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.</t>
<t>Host routes for stub networks no longer appear in the router-LSA.
Rather, they are included in intra-area-prefix-LSAs.</t>
</section>
<section anchor="network-lsa" title="Network-LSAs">
<t>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 whom it is fully adjacent.</t>
<t>The procedure for originating network-LSAs in IPv6 is the same as the
IPv4 procedure documented in Section 12.4.2 of <xref target="OSPFV2"/>, with the
following exceptions:
<vspace blankLines="1" /><list style="symbols">
<t>An IPv6 network-LSA's Link State ID is set to the Interface ID of
the Designated Router on the link.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>As an example, assuming that Router RT4 has been elected Designated
Router of Network N3 in Figure 1, the following network-LSA is
originated:
<figure title="Network-LSA for Network N3">
<artwork>
; 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
</artwork>
</figure></t>
</section>
<section anchor="inter-area-prefix-lsa" title="Inter-Area-Prefix-LSAs">
<t>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.</t>
<t>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 <xref target="OSPFV2"/>, with the following exceptions:
<vspace blankLines="1" /><list style="symbols">
<t>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.</t>
<t>The prefix is described by the PrefixLength, PrefixOptions, and
Address Prefix fields embedded within the LSA body. Network Mask
is no longer specified.</t>
<t>The NU-bit in the PrefixOptions field should be clear.</t>
<t>Link-local addresses MUST never be advertised in
inter-area-prefix-LSAs.</t>
</list></t>
<t>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.
<figure title="Inter-area-prefix-LSA for Area 1 addresses originated
by Router RT4 into the backbone">
<artwork>
; 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
</artwork>
</figure></t>
</section>
<section anchor="inter-area-router-lsa" title="Inter-Area-Router-LSAs">
<t>The LS type of an inter-area-router-LSA is set to the value
0x2004. Inter-area-router-LSAs have area flooding scope. In IPv4,
inter-area-router-LSAs were called type 4 summary-LSAs. Each
inter-area-router-LSA describes a path to a destination OSPF
router (an AS Boundary Router or ASBR) that is external to the
area yet internal to the Autonomous System.</t>
<t>The procedure for originating inter-area-router-LSAs in IPv6 is
the same as the IPv4 procedure documented in Section 12.4.3 of
<xref target="OSPFV2"/>, with the following exceptions:
<vspace blankLines="1" /><list style="symbols">
<t>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.</t>
<t>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.</t>
</list></t>
<t>As an example, consider the OSPF Autonomous System depicted in Figure
6 of <xref target="OSPFV2"/>. Router RT4 would originate into Area 1 the following
inter-area-router-LSA for destination router RT7.
<figure title="Inter-area-router-LSA for AS boundary router RT7
originated by Router RT4 into Area 1">
<artwork>
; 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
</artwork>
</figure></t>
</section>
<section anchor="external-lsa" title="AS-external-LSAs">
<t>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.</t>
<t>The procedure for originating AS-external-LSAs in IPv6 is the same as
the IPv4 procedure documented in Section 12.4.4 of <xref target="OSPFV2"/>, with the
following exceptions:
<vspace blankLines="1" /><list style="symbols">
<t>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.</t>
<t>The prefix is described by the PrefixLength, PrefixOptions, and
Address Prefix fields embedded within the LSA body. Network Mask
is no longer specified.</t>
<t>The NU-bit in the PrefixOptions field should be clear.</t>
<t>Link-local addresses can never be advertised in AS-external-LSAs.</t>
<t>The forwarding address is present in the AS-external-LSA if and
only if the AS-external-LSA's bit F is set.</t>
<t>The external route tag is present in the AS-external-LSA if and
only if the AS-external-LSA's bit T is set.</t>
<t>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 Referenced LS Type is non-zero). This capability is
for future use; Referenced LS Type should be set to 0 and
received non-zero values for this field should be ignored until
its use is defined.</t>
</list></t>
<t>As an example, consider the OSPF Autonomous System depicted in Figure
6 of <xref target="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.
<figure title="AS-external-LSA for Network N12, originated by Router RT7">
<artwork>
; AS-external-LSA for Network N12,
; originated by Router RT7
LS age = 0 ;newly (re)originated
LS type = 0x4005 ;AS-external-LSA
Link State ID = 123 ;or something else
Advertising Router = Router RT7's ID
bit E = 1 ;Type 2 metric
bit F = 0 ;no forwarding address
bit T = 1 ;external route tag included
Metric = 2
PrefixLength = 40
PrefixOptions = 0
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
</artwork>
</figure></t>
</section>
<section anchor="nssa-lsa" title="NSSA-LSAs">
<t>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.</t>
<t>The procedure for originating NSSA-LSAs in IPv6 is the same as
the IPv4 procedure documented in <xref target="NSSA"/>, with the
following exceptions:
<vspace blankLines="1" /><list style="symbols">
<t>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.</t>
<t>The prefix is described by the PrefixLength, PrefixOptions, and
Address Prefix fields embedded within the LSA body. Network Mask
is no longer specified.</t>
<t>The NU-bit in the PrefixOptions field should be clear.</t>
<t>Link-local addresses can never be advertised in NSSA-LSAs.</t>
<t>The forwarding address is present in the NSSA-LSA if and
only if the NSSA-LSA's bit F is set.</t>
<t>The external route tag is present in the NSSA-LSA if and
only if the NSSA-LSA's bit T is set.</t>
<t>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 Referenced LS Type is non-zero). This capability is
for future use; Referenced LS Type should be set to 0 and
received non-zero values for this field should be ignored until
its use is defined.</t>
</list></t>
<t>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.</t>
</section>
<section anchor="link-lsa" title="Link-LSAs">
<t>The LS type of a link-LSA is set to the value 0x0008. Link-LSAs have
link-local flooding scope. A router originates a separate link-LSA
for each attached link that supports 2 or more (including the
originating router itself) routers. Link-LSAs SHOULD NOT be originated
for virtual links.</t>
<t>Link-LSAs have three purposes:
<vspace blankLines="1" /><list style="numbers">
<t>They provide the router's link-local address to all other routers
attached to the link.</t>
<t>They inform other routers attached to the link of a list of IPv6 prefixes
to associate with the link.</t>
<t>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.</t>
</list></t>
<t>A link-LSA for a given Link L is built in the following fashion:
<vspace blankLines="1" /><list style="symbols">
<t>The Link State ID is set to the router's Interface ID on Link L.</t>
<t>The Router Priority of the router's interface to Link L is
inserted into the link-LSA.</t>
<t>The link-LSA's Options field is set to those bits that the router
wishes set in Link L's Network LSA.</t>
<t>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 <xref target="next-hop-calc"/>).</t>
<t>Each IPv6 address prefix that has been configured on Link L
is added to the link-LSA by specifying values for
PrefixLength, PrefixOptions, and Address Prefix fields.</t>
</list></t>
<t>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.</t>
<t>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 <xref target="next-hop-calc"/>). Refer to
<xref target="intf-config"/> for a description of the
LinkLSASuppression interface configuration parameter.</t>
<t>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.
<figure title="RT3's link-LSA for N3">
<artwork>
; 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
</artwork>
</figure></t>
</section>
<section anchor="intra-area-prefix-lsa" title="Intra-Area-Prefix-LSAs">
<t>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.</t>
<t>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.</t>
<t>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:
<vspace blankLines="1" /><list style="symbols">
<t>In order to indicate that the prefixes are to be associated with
the Link L, the fields Referenced LS Type, Referenced Link State
ID, and Referenced Advertising Router are set to the corresponding
fields in Link L's network-LSA (namely LS type, Link State ID, and
Advertising Router respectively). This means that Referenced LS Type
is set to 0x2002, Referenced Link State ID is set to the Designated
Router's Interface ID on Link L, and Referenced Advertising Router
is set to the Designated Router's Router ID.</t>
<t>Each link-LSA associated with Link L is examined (these are in the
Designated Router's interface structure for Link L). If the link-LSA's
Advertising Router is fully adjacent to the Designated
Router 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 Prefix
Options 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.</t>
<t>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.</t>
</list></t>
<t>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:
<vspace blankLines="1" /><list style="symbols">
<t>In order to indicate that the prefixes are to be associated with
the Router RTX itself, RTX sets Referenced LS Type to 0x2001,
Referenced Link State ID to 0, and Referenced Advertising Router
to RTX's own Router ID.</t>
<t>Router RTX examines its list of interfaces to the area. If the
interface is in state Down, its prefixes are not included. If the
interface has been reported in RTX's router-LSA as a Type 2 link
description (link to transit network), prefixes which will be
included in the intra-area-prefix-LSA for the link are skipped.
However, any prefixes which 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 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.</t>
<t>RTX adds the IPv6 prefixes for any directly attached hosts
belonging to the area (see <xref target="host-config"/>)
to the intra-area-prefix-LSA.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>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.
<figure title="Intra-area-prefix-LSA for network link N3">
<artwork>
; 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 ;or something
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 ;or something
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
</artwork>
</figure></t>
<t>When network conditions change, it may be necessary for a router to
move prefixes from one intra-area-prefix-LSA to another. For example,
if the router is Designated Router for a link but the link has no
other attached routers, the link's prefixes are advertised in an
intra-area-prefix-LSA referring to the Designated Router's router-LSA.
When additional routers appear on the link, a network-LSA is
originated for the link and the link's prefixes are moved to an
intra-area-prefix-LSA referring to the network-LSA.</t>
<t>Note that in the intra-area-prefix-LSA, the "Referenced Advertising
Router" is always equal to the router that is originating the intra-
area-prefix-LSA (i.e., the LSA's Advertising Router). The reason that
the Referenced Advertising Router field appears is that, even though
it is currently redundant, it may not be in the future. We may
sometime want to use the same LSA format to advertise address
prefixes for other protocol suites. In this case, the Designated
Router may not 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, "Referenced Advertising Router"
and "Advertising Router" would be different.</t>
</section>
</section>
<section anchor="new-lsa" title="Future LSA Validation">
<t>It is expected that new LSAs will be defined that will not be processed
during the Shortest Path First (SPF) calculation as described in <xref target="spf"/>.
For example, OSPFv3 LSAs corresponding to information advertised in OSPFv2 using
opaque LSAs <xref target="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.</t>
<t>To facilitate inter-area reachability validation, any OSPFv3 router originating
AS scoped LSAs is considered an AS Boundary Router (ASBR).</t>
</section>
</section>
<section anchor="flooding" title="Flooding">
<t>Most of the flooding algorithm remains unchanged from the IPv4
flooding mechanisms described in Section 13 of <xref target="OSPFV2"/>. In particular,
the protocol processes for determining which LSA instance is newer (Section
13.1 of <xref target="OSPFV2"/>), responding to updates of self-originated LSAs
(Section 13.4 of <xref target="OSPFV2"/>), sending Link State Acknowledgment packets
(Section 13.5 of <xref target="OSPFV2"/>), retransmitting LSAs (Section 13.6 of
<xref target="OSPFV2"/>), and receiving Link State Acknowledgment packets (Section 13.7
of <xref target="OSPFV2"/>) are exactly the same for IPv6 and IPv4.</t>
<t>However, the addition of flooding scope and unknown LSA type
handling (see <xref target="lsa-type"/>) has
caused some changes in the OSPF flooding algorithm: the reception
of Link State Updates
(Section 13 in <xref target="OSPFV2"/>) and the sending of Link State Updates (Section
13.3 of <xref target="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 <xref target="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.</t>
<section anchor="receive-lsu" title="Receiving Link State Update packets">
<t>The encoding of flooding scope in the LS type and the need to process
unknown LS types causes modifications to the processing of received
Link State Update packets. As in IPv4, each LSA in a received Link
State Update packet is examined. In IPv4, eight steps are executed
for each LSA, as described in Section 13 of <xref target="OSPFV2"/>. For IPv6, all the
steps are the same, except that Steps 2 and 3 are modified as
follows:</t>
<figure title="">
<artwork>
(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.
</artwork>
</figure>
<t>Steps 5b (sending Link State Update packets) and 5d (installing LSAs
in the link-state database) in Section 13 of <xref target="OSPFV2"/> are also somewhat
different for IPv6, as described in Sections 3.5.2 and 3.5.3 below.</t>
</section>
<section anchor="ls-update-send" title="Sending Link State Update packets">
<t>The sending of Link State Update packets is described in Section 13.3
of <xref target="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
<xref target="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:
<vspace blankLines="1" /><list style="symbols">
<t>The LSA's flooding scope.</t>
<t>For LSAs with area or link-local flooding scoping, the particular
area or interface that the LSA is associated with.</t>
<t>Whether the LSA has a recognized LS type.</t>
<t>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.</t>
</list></t>
<t>Choosing the set of eligible interfaces then breaks into the
following cases:
<vspace blankLines="1" /><list style="hanging">
<t hangText="Case 1"><vspace blankLines="0" />
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 set of eligible interfaces are those
interfaces connecting to the LSA's associated area. If the
flooding scope is "link-local flooding scope", then there is a
single eligible interface, the one connecting to the LSA's
associated link (which is also the interface on which the LSA was
received in a Link State Update packet).</t>
<t hangText="Case 2"><vspace blankLines="0" />
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.</t>
<t hangText="Case 3"><vspace blankLines="0" />
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 understood). In this
case, select the eligible interfaces based on the encoded flooding
scope the same as in Case 1 above.</t>
</list></t>
<t>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 <xref target="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 Designated Router or Backup Designated Router for
the attached link.</t>
<t>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.</t>
</section>
<section title="Installing LSAs in the database">
<t>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 <xref target="data-struct"/>)
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 <xref target="area-data-struct"/>) 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.</t>
<t>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 <xref target="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:
<vspace blankLines="1" /><list style="hanging">
<t hangText="Router-LSAs, Network-LSAs, Intra-Area-Prefix-LSAs, and Link-LSAs">
<vspace blankLines="0" />
The entire routing table is recalculated, starting with the
shortest path calculation for each area
(see <xref target="spf"/>).</t>
<t hangText="Inter-Area-Prefix-LSAs and Inter-Area-Router-LSAs">
<vspace blankLines="0" />
The best route to the destination described by the LSA must be
recalculated (see Section 16.5 in <xref target="OSPFV2"/>). If this destination is
an AS boundary router, it may also be necessary to re-examine all
the AS-external-LSAs.</t>
<t hangText="AS-external-LSAs and NSSA-LSAs"><vspace blankLines="0" />
The best route to the destination described by the AS-external-LSA
or NSSA-LSA must be recalculated (see Section 16.6 in <xref target="OSPFV2"/>
and Section 2.0 in <xref target="NSSA"/>).</t>
</list></t>
<t>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.</t>
</section>
</section>
<section title="Definition of self-originated LSAs">
<t>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
<xref target="OSPFV2"/>. For IPv6, self-originated LSAs are those LSAs whose
Advertising Router is equal to the router's own Router ID.</t>
</section>
<section anchor="virtual-link" title="Virtual links">
<t>OSPF virtual links for IPv4 are described in Section 15 of <xref target="OSPFV2"/>.
Virtual links are the same in IPv6, with the following exceptions:
<vspace blankLines="1" /><list style="symbols">
<t>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.</t>
<t>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.</t>
<t>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 <xref target="intra-area-prefix-lsa"/> and
<xref target="intra-spf"/>).</t>
<t>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.</t>
</list></t>
</section>
<section anchor="spf" title="Routing table calculation">
<t>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 <xref target="OSPFV2"/>. High level differences between the IPv6 and
IPv4 calculations include:
<vspace blankLines="1" /><list style="symbols">
<t>Prefix information has been removed from router-LSAs and network-LSAs and
is now advertised in intra-area-prefix-LSAs. Whenever <xref target="OSPFV2"/> specifies
that stub networks within router-LSAs be examined, IPv6 will
instead examine prefixes within intra-area-prefix-LSAs.</t>
<t>Type 3 and 4 summary-LSAs have been renamed inter-area-prefix-LSAs
and inter-area-router-LSAs respectively.</t>
<t>Addressing information is no longer encoded in Link State IDs and
is now only found within the body of LSAs.</t>
<t>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 <xref target="intra-spf"/>).</t>
</list></t>
<t>For each area, the shortest-path tree calculation creates routing table
entries for the area's routers and transit links (see <xref target="intra-spf"/>).
These entries are then used
when processing intra-area-prefix-LSAs,
inter-area-prefix-LSAs, and inter-area-router-LSAs, as described in
<xref target="inter-spf"/>.</t>
<t>Events generated as a result of routing table changes (Section 16.7
of <xref target="OSPFV2"/>) and the equal-cost multipath logic (Section 16.8 of
<xref target="OSPFV2"/>) are identical for both IPv4 and IPv6.</t>
<section anchor="intra-spf"
title="Calculating the shortest path tree for an area">
<t>The IPv4 shortest path calculation is contained in Section 16.1 of
<xref target="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 <xref target="route-table"/>).</t>
<t>Section 16.1 of <xref target="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.</t>
<t>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 <xref target="OSPFV2"/>):
<vspace blankLines="1" /><list style="symbols">
<t>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.</t>
<t>In Step 2, when a router Vertex V has just been added to the
shortest path tree, there may be multiple LSAs associated with the
router. All router-LSAs with Advertising Router set to V's OSPF
Router ID MUST be processed as an aggregate, treating them as
fragments of a single large router-LSA. The Options field and the
router type bits (bits Nt, V, E, and B) should always be taken from
router-LSA with the smallest Link State ID.</t>
<t>Step 2a is not needed in IPv6, as there are no longer stub network
links in router-LSAs.</t>
<t>In Step 2b, if W is a router and the router LSA V6-bit or R-bit
are not set in the LSA options, the transit link W is ignored
and V's next link is examined.</t>
<t>In Step 2b, if W is a router, there may again be multiple LSAs
associated with the router. All router-LSAs with Advertising
Router set to W's OSPF Router ID MUST be processed as an aggregate,
treating them as fragments of a single large router-LSA.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>The next stage of the shortest path calculation proceeds similarly to
the two steps of the second stage of Section 16.1 in <xref target="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.</t>
<t>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 be bidirectional for inclusion in the tree.
Alternate algorithms and optimizations are beyond the scope of this
specification.</t>
</section>
<section anchor="next-hop-calc" title="The next hop calculation">
<t>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 <xref target="OSPFV2"/>). However,
there are some differences. When calculating the next hop IPv6 address for a router
(call it Router X) which 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 <xref target="link-lsa-format"/>) 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.</t>
<t>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 <xref target="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.</t>
</section>
<section anchor="inter-spf" title="Calculating the inter-area routes">
<t>Calculation of inter-area routes for IPv6 proceeds along the same
lines as the IPv4 calculation in Section 16.2 of <xref target="OSPFV2"/>, with the
following modifications:
<vspace blankLines="1" /><list style="symbols">
<t>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.</t>
<t>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.</t>
<t>Prefixes having the "NU-bit" set in their Prefix Options field
should be ignored by the inter-area route calculation.</t>
</list></t>
<t>When a single inter-area-prefix-LSA or inter-area-router-LSA has
changed, the incremental calculations outlined in Section 16.5 of
<xref target="OSPFV2"/> can be performed instead of recalculating the entire routing
table.</t>
</section>
<section title="Examining transit areas' summary-LSAs">
<t>Examination of transit areas' summary-LSAs in IPv6 proceeds along the
same lines as the IPv4 calculation in Section 16.3 of <xref target="OSPFV2"/>,
modified in the same way as the IPv6 inter-area route calculation in
<xref target="inter-spf"/>.</t>
</section>
<section anchor="ext-spf" title="Calculating AS external and NSSA routes">
<t>The IPv6 AS external route calculation proceeds along the same lines
as the IPv4 calculation in Section 16.4 of <xref target="OSPFV2"/> and Section 2.5 of
<xref target="NSSA" />, with the following exceptions:
<vspace blankLines="1" /><list style="symbols">
<t>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.</t>
<t>The default route in AS-external-LSAs or NSSA-LSAs is advertised
by a zero length prefix.</t>
<t>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.</t>
<t>Prefixes having the "NU-bit" set in their Prefix Options field
should be ignored by the inter-area route calculation.</t>
<t>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 <xref target="global-config"/>.</t>
</list></t>
<t>When a single AS-external-LSA or NSSA-LSA has changed, the incremental
calculations outlined in Section 16.6 of <xref target="OSPFV2"/> can be performed
instead of recalculating the entire routing table.</t>
</section>
</section>
<section anchor="multi-intf" title="Multiple interfaces to a single link">
<t>In OSPF for IPv6, a router may have multiple interfaces to a single
link associated with the same OSPF instance and area. All interfaces
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:
<vspace blankLines="1" /><list style="symbols">
<t>Each of the multiple interfaces are assigned different Interface
IDs. 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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>Any link-local scope LSAs which are originated for a Standby
Interface will be flooded over the Active Interface.
<vspace blankLines="0" />
If a Standby Interface goes down then the
link-local scope LSAs originated for the Standby Interfaces
MUST be flushed on the Active Interface.</t>
<t>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
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.</t>
<t>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.</t>
<t>If the network becomes partitioned with different local interfaces
attaching to different network partitions, multiple interfaces will
become Active Interfaces and function independently.</t>
<t>During the SPF calculation when a network-LSA for a network which
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.
<vspace blankLines="0" />
This can be accomplished during the back link check (see
section 16.1 Step 2 (B) in <xref target="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.</t>
<t>The interface state machine is modified to add the state Standby.
See <xref target="standby"/> for a description of the
Standby state.</t>
</list></t>
<section anchor="standby" title="Standby Interface State">
<t>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.</t>
<t>Two new events are added to the list of events which cause
interface state changes: MultipleInterfacesToLink and
ActiveInterfaceDead. The descriptions of these events are as
follows:
<vspace blankLines="1" /><list style="hanging">
<t hangText="MultipleInterfacesToLink"><vspace blankLines="0" />
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.</t>
<t hangText="ActiveInterfaceDead"><vspace blankLines="0" />
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.</t>
</list></t>
<t>Interface state machine additions include:
<figure title="Standby Interface State Machine Additions">
<artwork>
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.
</artwork>
</figure></t>
</section>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>When running over IPv6, OSPF relies on the IP Authentication Header
(see <xref target="IPAUTH" />) and the IP Encapsulating Security
Payload (see <xref target="IPESP"/>)
to ensure integrity and authentication/confidentiality of
protocol packets. This is described in <xref target="OSPFV3-AUTH"/>.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>Most OSPF for IPv6 IANA considerations are documented in <xref target="OSPF-IANA"/>.
IANA is requested to change the reference for RFC2740 to this document.
(to be removed before publication)</t>
<t>Additionally, this document introduces the following IANA requirements that were not present
in <xref target="OSPFV3"/>:
<vspace blankLines="1" /><list style="symbols">
<t>Reserve the options with the values 0x000040 and 0x000080 for migrated OSPFv2 options
in the OSPFv3 Options registry defined in
<xref target="OSPF-IANA"/>. For information on the OSPFv3 Options Field refer to
<xref target="options-field"/>.</t>
<t>Add prefix option P-bit with value 0x08 to the OSPFv3 Prefix Options registry defined in
<xref target="OSPF-IANA"/>. For information on OSPFv3 Prefix Options refer to
<xref target="prefix-options"/>.</t>
<t>Add prefix option DN-bit with value 0x10 to the OSPFv3 Prefix Options registry defined in
<xref target="OSPF-IANA"/>. For information on OSPFv3 Prefix Options refer to
<xref target="prefix-options"/>.</t>
</list></t>
<section anchor="iana-mospf-deprecation" title="MOSPF for OSPFv3 Deprecation IANA Considerations">
<t>With the deprecation of MOSPF for OSPFv3, the following code points are available for
reassignment. Refer to <xref target="OSPF-IANA"/> for information on the respective registries.
<vspace blankLines="1" /><list style="symbols">
<t>Deprecate the MC-bit with value 0x000004 in the OSPFv3 Options Registry.</t>
<t>Deprecate Group-membership-LSA with value 6 in OSPFv3 LSA Function Code Registry.</t>
<t>Deprecate MC-bit with value 0x04 in the OSPFv3 Prefix Options Registry.</t>
</list></t>
<t>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.
<figure title="OSPFv3 Router Properties Registry">
<artwork>
Registry Name: OSPFv3 Router Properties Registry
Reference: RFC-ietf-ospf-ospfv3-update (This Document)
Registration Procedures: Standards Action
Registry:
Value Description Reference
------ ------------- ---------
0x01 B-bit RFC-ietf-ospf-ospfv3-update (This Document)
0x02 E-bit RFC-ietf-ospf-ospfv3-update (This Document)
0x04 V-bit RFC-ietf-ospf-ospfv3-update (This Document)
0x08 Deprecated RFC-ietf-ospf-ospfv3-update (This Document)
0x10 Nt-bit RFC-ietf-ospf-ospfv3-update (This Document)
</artwork>
</figure></t>
</section>
</section>
<section title="Acknowledgments">
<t>The RFC text was produced using Marshall Rose's xml2rfc tool.</t>
<t>The following individuals contributed comments which that
incorporated into this document:
<vspace blankLines="1" /><list style="symbols">
<t>Harold Rabbie for his description of protocol details which needed to
be clarified for OSPFv3 NSSA support.</t>
<t>Nic Neate for his pointing out that there needed to be changes for
unknown LSA types handling in the processing of Database Description
packets.</t>
<t>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.</t>
<t>Michael Barnes recognized that the support for
multiple interfaces to a single link was broken
(see <xref target="multi-intf"/>) and provided the
description of the current protocol mechanisms. Abhay Roy reviewed
and suggested improvements to the mechanisms.</t>
<t>Alan Davey reviewed and commented on draft revisions.</t>
<t>Vivek Dubey reviewed and commented on draft revisions.</t>
<t>Manoj Goyal and Vivek Dubey complained enough about link-LSAs being
unnecessary to compel introduction of the LinkLSASuppression
interface configuration parameter.</t>
<t>Manoj Goyal for pointing out that the next-hop calculation for
intra-area-prefix-LSAs corresponding to network vertices was
unclear.</t>
<t>Ramana Koppula reviewed and commented on draft revisions.</t>
<t>Paul Wells reviewed and commented on draft revisions.</t>
<t>Amir Khan reviewed and commented on draft revisions.</t>
<t>Dow Street and Wayne Wheeler commented on the addition of the
DN bit to OSPFv3.</t>
<t>Mitchell Erblichs provided numerous editorial comments.</t>
<t>Russ White provided numerous editorial comments.</t>
<t>Kashima Hiroaki provided editorial comments.</t>
<t>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.</t>
<t>Faraz Shamin reviewed a late version of the draft and provided
editorial comments.</t>
<t>Christian Vogt performed the General Area Review Team (Gen-ART) review
and provided comments.</t>
</list></t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC-KEYWORDS">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="RFC" value="2119" />
</reference>
<reference anchor="OSPFV2">
<front>
<title>OSPF Version 2</title>
<author initials="J." surname="Moy" fullname="John Moy">
<organization>Ascend Communications, Inc</organization>
</author>
<date month="April" year="1998" />
</front>
<seriesInfo name="RFC" value="2328" />
</reference>
<reference anchor="OSPF-IANA">
<front>
<title>IANA Considerations for OSPF</title>
<author initials="K." surname="Kompella" fullname="Kireeti Kompella">
<organization>Juniper Networks</organization>
</author>
<author initials="B." surname="Fenner" fullname="Bill Fenner">
<organization>AT&T Labs--Research</organization>
</author>
<date month="July" year="2007" />
</front>
<seriesInfo name="RFC" value="4940" />
</reference>
<reference anchor="INTFMIB">
<front>
<title>The interfaces Group MIB</title>
<author initials="K." surname="McCloghrie" fullname="Keith McCloghrie">
<organization>Cisco Systems</organization>
</author>
<author initials="F." surname="Kastenholz" fullname="Frank Kastenholz">
<organization>Argon Networks</organization>
</author>
<date month="June" year="2000" />
</front>
<seriesInfo name="RFC" value="2863" />
</reference>
<reference anchor="DEMAND">
<front>
<title>Extending OSPF to Support Demand Circuits</title>
<author initials="J." surname="Moy" fullname="John Moy">
<organization>Proteon Inc</organization>
</author>
<date month="April" year="1995" />
</front>
<seriesInfo name="RFC" value="1793" />
</reference>
<reference anchor="NSSA">
<front>
<title>The OSPF Not-So-Stubby Area (NSSA) Option</title>
<author initials="P." surname="Murphy" fullname="Pat Murphy">
<organization>US Geological Survey</organization>
</author>
<date month="January" year="2003" />
</front>
<seriesInfo name="RFC" value="3101" />
</reference>
<reference anchor="IPV6">
<front>
<title>Internet Protocol, Version 6 (IPv6) Specification</title>
<author initials="S." surname="Deering" fullname="Steve Deering">
<organization>Cisco Systems</organization>
</author>
<author initials="R." surname="Hinden" fullname="Robert M. Hinden">
<organization>Nokia</organization>
</author>
<date month="December" year="1998" />
</front>
<seriesInfo name="RFC" value="2460" />
</reference>
<reference anchor="IP6ADDR">
<front>
<title>IP Version 6 Addressing Architecture</title>
<author initials="R." surname="Hinden" fullname="Robert M. Hinden">
<organization>Nokia</organization>
</author>
<author initials="S." surname="Deering" fullname="Steve Deering">
<organization>Cisco Systems</organization>
</author>
<date month="February" year="2006" />
</front>
<seriesInfo name="RFC" value="4291" />
</reference>
<reference anchor="OSPFV3-AUTH">
<front>
<title>Authentication/Confidentiality for OSPFv3</title>
<author initials="M." surname="Gupta" fullname="Murkesh Gupta">
<organization>Tropos Networks</organization>
</author>
<author initials="S." surname="Melam" fullname="Nagavenkata Suresh Melam">
<organization>Juniper Networks</organization>
</author>
<date month="June" year="2006" />
</front>
<seriesInfo name="RFC" value="4552" />
</reference>
<reference anchor="IPAUTH">
<front>
<title>IP Authentication Header</title>
<author initials="S." surname="Kent" fullname="Steven Kent">
<organization>BBN Technologies</organization>
</author>
<date month="December" year="2005" />
</front>
<seriesInfo name="RFC" value="4302" />
</reference>
<reference anchor="IPESP">
<front>
<title>IP Encapsulation Security Payload (ESP)</title>
<author initials="S." surname="Kent" fullname="Steven Kent">
<organization>BBN Corp</organization>
</author>
<date month="December" year="2005" />
</front>
<seriesInfo name="RFC" value="4303" />
</reference>
<reference anchor="DN-BIT">
<front>
<title>Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs</title>
<author initials="E." surname="Rosen" fullname="Eric Rosen">
<organization>Cisco Systems</organization>
</author>
<author initials="P." surname="Peter" fullname="Peter Psenak">
<organization>Cisco Systems</organization>
</author>
<author initials="P." surname="Pillay-Esnault" fullname="Padma Pillay-Esnault">
<organization>Juniper Networks</organization>
</author>
<date month="April" year="2005" />
</front>
<seriesInfo name="RFC" value="4576" />
</reference>
<reference anchor="IPV4">
<front>
<title>Internet Protocol</title>
<author initials="J." surname="Postal" fullname="Jon Postal">
<organization>ISI</organization>
</author>
<date month="September" year="1981" />
</front>
<seriesInfo name="RFC" value="791" />
</reference>
<reference anchor="DIFF-SERV">
<front>
<title>Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers</title>
<author initials="K." surname="Nichols" fullname="Kathleen Nichols">
<organization>Cisco Systems</organization>
</author>
<author initials="S." surname="Blake" fullname="Steven Blake">
<organization>Cisco Systems</organization>
</author>
<author initials="F." surname="Baker" fullname="Fred Baker">
<organization>Cisco Systems</organization>
</author>
<author initials="D." surname="Black" fullname="David Black">
<organization>EMC Corporation</organization>
</author>
<date month="December" year="1998" />
</front>
<seriesInfo name="RFC" value="2474" />
</reference>
</references>
<references title="Informative References">
<reference anchor="OSPFV3">
<front>
<title>OSPF for IPv6</title>
<author initials="R." surname="Coltun" fullname="Rob Coltun">
<organization>Siara Systems</organization>
</author>
<author initials="D." surname="Ferguson" fullname="Dennis Ferguson">
<organization>Juniper Network, Inc</organization>
</author>
<author initials="J." surname="Moy" fullname="John Moy">
<organization>Sycamore Systems, Inc</organization>
</author>
<date month="December" year="1999" />
</front>
<seriesInfo name="RFC" value="2740" />
</reference>
<reference anchor="OPAQUE">
<front>
<title>The OSPF Opaque LSA Option</title>
<author initials="R." surname="Coltun" fullname="Rob Colton">
<organization>FORE Systems</organization>
</author>
<date month="July" year="1998" />
</front>
<seriesInfo name="RFC" value="2370" />
</reference>
<reference anchor="MTUDISC">
<front>
<title>Path MTU Discovery</title>
<author initials="J." surname="Mogul" fullname="Jeffrey Mogul">
<organization>Digital Equipment Corp</organization>
</author>
<author initials="S." surname="Deering" fullname="Steve Deering">
<organization>Xerox PARC</organization>
</author>
<date month="November" year="1990" />
</front>
<seriesInfo name="RFC" value="1191" />
</reference>
<reference anchor="MOSPF">
<front>
<title>Multicast Extensions to OSPF</title>
<author initials="J." surname="Moy" fullname="John Moy">
<organization>Proteon Inc</organization>
</author>
<date month="March" year="1994" />
</front>
<seriesInfo name="RFC" value="1584" />
</reference>
<reference anchor="SERV-CLASS">
<front>
<title>Configuration Guidelines ofr DiffServ Service Classes</title>
<author initials="F." surname="Baker" fullname="Fred Baker">
<organization>Cisco Systems</organization>
</author>
<author initials="K." surname="Chan" fullname="Kwok Ho Chan">
<organization>Nortel Networks</organization>
</author>
<author initials="J." surname="Babiarz" fullname="Jozef Babiarz">
<organization>Nortel Networks</organization>
</author>
<date month="August" year="2006" />
</front>
<seriesInfo name="RFC" value="4594" />
</reference>
</references>
<section title="OSPF data formats">
<t>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.</t>
<t>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.</t>
<t>OSPF packet formats are detailed in Section A.3.</t>
<t>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.</t>
<section anchor="encap" title="Encapsulation of OSPF packets">
<t>OSPF runs directly over the IPv6's network layer. OSPF packets are
therefore encapsulated solely by IPv6 and local data-link headers.</t>
<t>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 <xref target="MTUDISC" />.</t>
<t>The other important features of OSPF's IPv6 encapsulation are:
<vspace blankLines="1" /><list style="symbols">
<t>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.
<vspace blankLines="1" /><list style="hanging">
<t hangText="AllSPFRouters"><vspace blankLines="0" />
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.</t>
<t hangText="AllDRouters"><vspace blankLines="0" />
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.</t>
</list></t>
<t>OSPF is IP protocol 89. This number SHOULD be inserted in the
Next Header field of the encapsulating IPv6 header.</t>
<t>The OSPFv2 specification (Appendix A.1 in <xref target="OSPFV2"/>) indicates
that OSPF protocol packets are sent with IP precedence
set to Internetwork Control (B'110') <xref target="IPV4"/>. If routers in
the OSPF routing domain map their IPv6 Traffic Class octet to the Differentiated
Services Code Point (DSCP) as specified in <xref target="DIFF-SERV"/>,
then OSPFv3 packets SHOULD be sent with their DSCP set to CS6 (B'110000'), as
specified in <xref target="SERV-CLASS"/>. In networks supporting this
mapping, OSPF packets will be given precedence over IPv6 data traffic.</t>
</list></t>
</section>
<section anchor="options-field" title="The Options field">
<t>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.</t>
<t>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.</t>
<t>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 Option bits in received Hello
packets, Database Description packets, or LSAs should ignore the
unrecognized bits and process the packet or LSA normally.
<figure title="The Options field">
<artwork>
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
</artwork>
</figure>
<vspace blankLines="1" /><list style="hanging">
<t hangText="V6-bit"><vspace blankLines="0" />
If this bit is clear, the router/link should be excluded from IPv6
routing calculations. See <xref target="spf"/>
for details.</t>
<t hangText="E-bit"><vspace blankLines="0" />
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 <xref target="OSPFV2"/>.</t>
<t hangText="x-Bit"><vspace blankLines="0" />
This bit was previously used by MOSPF (see <xref target="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.</t>
<t hangText="N-bit"><vspace blankLines="0" />
This bit indicates whether or not the router is attached to an NSSA
as specified in <xref target="NSSA" />.</t>
<t hangText="R-bit"><vspace blankLines="0" />
This bit (the `Router' bit) indicates whether the originator is an
active router. If the router bit is clear, then routes which transit the
advertising node cannot be computed. Clearing the router bit would
be appropriate for a multi-homed host that wants to participate in
routing, but does not want to forward non-locally addressed
packets.</t>
<t hangText="DC-bit"><vspace blankLines="0" />
This bit describes the router's handling of demand circuits, as
specified in <xref target="DEMAND" />.</t>
<t hangText="*-bit"><vspace blankLines="0" />
These bits are reserved for migration of OSPFv2 protocol
extensions.</t>
</list></t>
</section>
<section title="OSPF Packet Formats">
<t>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.</t>
<t>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.</t>
<t>The receive processing of OSPF packets is detailed in
<xref target="proto-receive"/>.
The sending of OSPF packets is explained in
<xref target="proto-send"/>.</t>
<section anchor="packet-header" title="The OSPF packet header">
<t>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
<xref target="proto-receive"/>.
<figure title="The OSPF Packet Header">
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<vspace blankLines="1" /><list style="hanging">
<t hangText="Version #"><vspace blankLines="0" />
The OSPF version number. This specification documents version 3
of the OSPF protocol.</t>
<t hangText="Type"><vspace blankLines="0" />
The OSPF packet types are as follows. See
<xref target="hello-format"/> through
<xref target="ls-ack-format"/> for details.
<figure>
<artwork>
Type Description
---------------------------------
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State Acknowledgment
</artwork>
</figure></t>
<t hangText="Packet length"><vspace blankLines="0" />
The length of the OSPF protocol packet in bytes. This length
includes the standard OSPF header.</t>
<t hangText="Router ID"><vspace blankLines="0" />
The Router ID of the packet's source.</t>
<t hangText="Area ID"><vspace blankLines="0" />
A 32 bit number identifying the area that this packet belongs to.
All OSPF packets are associated with a single area. Most travel
a single hop only. Packets traversing a virtual link are
labeled with the backbone Area ID of 0.</t>
<t hangText="Checksum"><vspace blankLines="0" />
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 [IPV6, section 8.1]. The "Upper-Layer
Packet Length" in the pseudo-header is set to value of the OSPF
packet header's length field. The Next Header value used in the
pseudo-header is 89. If the packet's length is not an integral
number of 16-bit words, the packet is padded with a byte of zero
before checksumming. Before computing the checksum, the checksum
field in the OSPF packet header is set to 0.</t>
<t hangText="Instance ID"><vspace blankLines="0" />
Enables multiple instances of OSPF to be run over a single link.
Each protocol instance would be assigned a separate Instance ID;
the Instance ID has local link significance only. Received
packets whose Instance ID is not equal to the receiving
interface's Instance ID are discarded.</t>
<t hangText="0"><vspace blankLines="0" />
These fields are reserved. They SHOULD be set to 0 when sending
protocol packets and MUST be ignored when receiving protocol
packets.</t>
</list></t>
</section>
<section anchor="hello-format" title="The Hello Packet">
<t>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.</t>
<t>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).
<figure title="The OSPF Hello Packet">
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
</artwork>
</figure>
<vspace blankLines="1" /><list style="hanging">
<t hangText="Interface ID"><vspace blankLines="0" />
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
(<xref target="INTFMIB"/>).</t>
<t hangText="Rtr Priority"><vspace blankLines="0" />
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.</t>
<t hangText="Options"><vspace blankLines="0" />
The optional capabilities supported by the router, as documented
in Section A.2.</t>
<t hangText="HelloInterval"><vspace blankLines="0" />
The number of seconds between this router's Hello packets.</t>
<t hangText="RouterDeadInterval"><vspace blankLines="0" />
The number of seconds before declaring a silent router down.</t>
<t hangText="Designated Router ID"><vspace blankLines="0" />
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.</t>
<t hangText="Backup Designated Router ID"><vspace blankLines="0" />
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.</t>
<t hangText="Neighbor ID"><vspace blankLines="0" />
The Router IDs of each router on the network with neighbor
state 1-Way or greater.</t>
</list></t>
</section>
<section title="The Database Description Packet">
<t>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.</t>
<figure title="The OSPF Database Description Packet">
<artwork>
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 -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| ... |
</artwork>
</figure>
<t>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 <xref target="OSPFV2"/>. The
reception of Database Description packets is documented in Section
10.6 of <xref target="OSPFV2"/>.
<vspace blankLines="1" /><list style="hanging">
<t hangText="Options"><vspace blankLines="0" />
The optional capabilities supported by the router, as documented
in Section A.2.</t>
<t hangText="Interface MTU"><vspace blankLines="0" />
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
<xref target="MTUDISC" />. Interface MTU should be set to 0 in Database Description
packets sent over virtual links.</t>
<t hangText="I-bit"><vspace blankLines="0" />
The Init bit. When set to 1, this packet is the first in the
sequence of Database Description packets.</t>
<t hangText="M-bit"><vspace blankLines="0" />
The More bit. When set to 1, it indicates that more Database
Description packets are to follow.</t>
<t hangText="MS-bit"><vspace blankLines="0" />
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.</t>
<t hangText="DD sequence number"><vspace blankLines="0" />
Used to sequence the collection of Database Description packets.
The initial value (indicated by the Init bit being set) should be
unique. The DD sequence number then increments until the complete
database description for both the master and slave routers have been
exchanged.</t>
</list></t>
<t>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
<xref target="lsa-header"/>.
It contains all the information required to uniquely identify
both the LSA and the LSA's current instance.</t>
</section>
<section title="The Link State Request Packet">
<t>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.</t>
<t>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.</t>
<t>The sending of Link State Request packets is documented in Section
10.9 of <xref target="OSPFV2"/>. The reception of Link State Request packets is
documented in Section 10.7 of <xref target="OSPFV2"/>.
<figure title="The OSPF List State Request Packet">
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
</artwork>
</figure></t>
<t>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.</t>
</section>
<section title="The Link State Update Packet">
<t>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.</t>
<t>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 <xref target="flooding"/>.
<figure title="The OSPF List State Request Packet">
<artwork>
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 |
+- +-+
| ... |
</artwork>
</figure>
<vspace blankLines="1" /><list style="hanging">
<t hangText="# LSAs"><vspace blankLines="0" />
The number of LSAs included in this update.</t>
</list></t>
<t>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
<xref target="lsa-header"/>. Detailed formats of the different
types of LSAs are described <xref target="lsa-formats"/>.</t>
</section>
<section anchor="ls-ack-format" title="The Link State Acknowledgment Packet">
<t>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 <xref target="OSPFV2"/>. The reception of Link State Acknowledgment
packets is documented in Section 13.7 of <xref target="OSPFV2"/>.</t>
<t>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 <xref target="OSPFV2"/> for details).</t>
<t>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.
<figure title="The OSPF List State Acknowledgment Packet">
<artwork>
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 -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
</artwork>
</figure></t>
<t>Each acknowledged LSA is described by its LSA header. The LSA header
is documented in <xref target="lsa-header"/>. It contains all the
information required to uniquely identify both the LSA and the LSA's current
instance.</t>
</section>
</section>
<section anchor="lsa-formats" title="LSA formats">
<t>This document defines eight distinct types of LSAs.
Each LSA begins with
a standard 20 byte LSA header. This header is explained in
<xref target="lsa-header"/>. Succeeding sections
describe each LSA type individually.</t>
<t>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 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 <xref target="flooding"/>
for more information concerning the flooding algorithm). This
collection of LSAs is called the link-state database.</t>
<t>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 <xref target="OSPFV2"/>). For the details of the routing table build process,
see <xref target="spf"/>.</t>
<section anchor="prefix-rep" title="IPv6 Prefix Representation">
<t>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).</t>
<t>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 <xref target="lsa-header"/>).
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.</t>
<t>The default route is represented by a prefix of length 0.</t>
<t>Examples of IPv6 Prefix representation in OSPF can be found in
<xref target="inter-area-prefix-lsa-format"/>,
<xref target="external-lsa-format"/>,
<xref target="nssa-lsa-format"/>,
<xref target="link-lsa-format"/>, and
<xref target="intra-area-prefix-lsa-format"/>.</t>
<section anchor="prefix-options" title="Prefix Options">
<t>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.
<figure title="The Prefix Options field">
<artwork>
0 1 2 3 4 5 6 7
+--+--+--+--+--+-+--+--+
| | | |DN| P|x|LA|NU|
+--+--+--+--+--+-+--+--+
</artwork>
</figure>
<vspace blankLines="1" /><list style="hanging">
<t hangText="NU-bit"><vspace blankLines="0" />
The "no unicast" capability bit. If set, the prefix should be
excluded from IPv6 unicast calculations. If not set, it should be
included.</t>
<t hangText="LA-bit"><vspace blankLines="0" />
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
<xref target="intra-area-prefix-lsa"/>. An implementation MAY
also set the LA-bit for prefixes advertised with a host PrefixLength (128).</t>
<t hangText="x-bit"><vspace blankLines="0" />
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.</t>
<t hangText="P-bit"><vspace blankLines="0" />
The "propagate" bit. Set on NSSA area prefixes that should be
readvertised by the translating NSSA area border <xref target="NSSA" />.</t>
<t hangText="DN-bit"><vspace blankLines="0" />
This bit controls an inter-area-prefix-LSAs or AS-external-LSAs
re-advertisement in a VPN environment as specified
in <xref target="DN-BIT" />.</t>
</list></t>
</section>
</section>
<section anchor="lsa-header" title="The LSA header">
<t>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.
<figure title="The LSA Header">
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<vspace blankLines="1" /><list style="hanging">
<t hangText="LS Age"><vspace blankLines="0" />
The time in seconds since the LSA was originated.</t>
<t hangText="LS Type"><vspace blankLines="0" />
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 <xref target="lsa-type"/> for a
detailed description of LS type.</t>
<t hangText="LS State ID"><vspace blankLines="0" />
The originating router's identifier for the LSA.
The combination of the LS State ID, LS type, and Advertising Router
uniquely identify the LSA in the link-state database.</t>
<t hangText="Advertising Router"><vspace blankLines="0" />
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.</t>
<t hangText="LS sequence number"><vspace blankLines="0" />
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
<xref target="OSPFV2"/> for more details.</t>
<t hangText="LS checksum"><vspace blankLines="0" />
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 <xref target="OSPFV2"/> for more details.</t>
<t hangText="length"><vspace blankLines="0" />
The length in bytes of the LSA. This includes the 20 byte LSA
header.</t>
</list></t>
<section anchor="lsa-type" title="LSA Type">
<t>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:
<figure title="LSA Type">
<artwork>
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|U |S2|S1| LSA Function Code |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
</artwork>
</figure></t>
<t>The U bit indicates how the LSA should be handled by a router which
does not recognize the LSA's function code. Its values are:
<figure title="U Bit">
<artwork>
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
</artwork>
</figure></t>
<t>The S1 and S2 bits indicate the flooding scope of the LSA. The values
are:
<figure title="Flooding Scope">
<artwork>
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
</artwork>
</figure></t>
<t>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 <xref target="NSSA" />) and
0x2006 which was previously used by MOSPF (see <xref target="MOSPF"/>).
MOSPF has been deprecated for OSPFv3. As shown below, each LSA function
code also implies a specific setting for the U, S1, and S2 bits.
<figure title="LSA function code">
<artwork>
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
</artwork>
</figure></t>
</section>
</section>
<section anchor="router-lsa-format" title="Router-LSAs">
<t>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 <xref target="router-lsa"/>). Router-LSAs are
only flooded throughout a single area.</t>
<figure title="Router LSA format">
<artwork>
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 |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
</artwork>
</figure>
<t>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.
<vspace blankLines="1" /><list style="hanging">
<t hangText="Bit V"><vspace blankLines="0" />
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).</t>
<t hangText="Bit E"><vspace blankLines="0" />
When set, the router is an AS boundary router (E is for external).</t>
<t hangText="Bit B"><vspace blankLines="0" />
When set, the router is an area border router (B is for border).</t>
<t hangText="Bit x"><vspace blankLines="0" />
This bit was previously used by MOSPF (see <xref target="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.</t>
<t hangText="Bit Nt"><vspace blankLines="0" />
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. <xref target="NSSA" /></t>
<t hangText="Options"><vspace blankLines="0" />
The optional capabilities supported by the router, as documented
in <xref target="options-field"/>).</t>
</list></t>
<t>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.
<vspace blankLines="1" /><list style="hanging">
<t hangText="Type"><vspace blankLines="0" />
The kind of interface being described. One of the following:
<figure title="Router Link Types">
<artwork>
Type Description
---------------------------------------------------
1 Point-to-point connection to another router
2 Connection to a transit network
3 Reserved
4 Virtual link
</artwork>
</figure></t>
<t hangText="Metric"><vspace blankLines="0" />
The cost of using this router interface for outbound traffic.</t>
<t hangText="Interface ID"><vspace blankLines="0" />
The Interface ID assigned to the interface being described. See
<xref target="intf-data-struct"/> and
<xref target="intf-config"/>.</t>
<t hangText="Neighbor Interface ID"><vspace blankLines="0" />
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.</t>
<t hangText="Neighbor Router ID"><vspace blankLines="0" />
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.</t>
</list></t>
<t>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.</t>
</section>
<section anchor="network-lsa-format" title="Network-LSAs">
<t>Network-LSAs have LS type equal to 0x2002. A network-LSA is
originated for each broadcast and NBMA link in the area which
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.</t>
<t>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
<xref target="network-lsa"/>).
<figure title="Network LSA format">
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
</artwork>
</figure>
<vspace blankLines="1" /><list style="hanging">
<t hangText="Attached Router"><vspace blankLines="0" />
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.</t>
</list></t>
</section>
<section anchor="inter-area-prefix-lsa-format"
title="Inter-Area-Prefix-LSAs">
<t>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 <xref target="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 <xref target="inter-area-prefix-lsa"/>).</t>
<t>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.
<figure title="Inter-Area-Prefix-LSA format">
<artwork>
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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<vspace blankLines="1" /><list style="hanging">
<t hangText="Metric"><vspace blankLines="0" />
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 <xref target="area-config"/>),
the cost is set to the maximum cost to any reachable component of
the address range.</t>
<t hangText="PrefixLength, PrefixOptions, and Address Prefix">
<vspace blankLines="0" />
Representation of the IPv6 address prefix, as described in
<xref target="prefix-rep"/></t>
</list></t>
</section>
<section anchor="inter-area-router-lsa-format"
title="Inter-Area-Router-LSAs">
<t>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 <xref target="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 <xref target="OSPFV2"/>. Each LSA describes a route to a single router. For
details concerning the construction of inter-area-router-LSAs, see
<xref target="inter-area-router-lsa"/>.
<figure title="Inter-Area-Router-LSA format">
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<vspace blankLines="1" /><list style="hanging">
<t hangText="Options"><vspace blankLines="0" />
The optional capabilities supported by the router, as documented
in <xref target="options-field"/>.</t>
<t hangText="Metric"><vspace blankLines="0" />
The cost of this route. Expressed in the same units as the
interface costs in router-LSAs.</t>
<t hangText="Destination Router ID"><vspace blankLines="0" />
The Router ID of the router being described by the LSA.</t>
</list></t>
</section>
<section anchor="external-lsa-format" title="AS-external-LSAs">
<t>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 <xref target="external-lsa"/>.</t>
<t>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.
<figure title="AS External LSA format">
<artwork>
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<vspace blankLines="1" /><list style="hanging">
<t hangText="bit E"><vspace blankLines="0" />
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).</t>
<t hangText="bit F"><vspace blankLines="0" />
If set, a Forwarding Address has been included in the LSA.</t>
<t hangText="bit T"><vspace blankLines="0" />
If set, an External Route Tag has been included in the LSA.</t>
<t hangText="Metric"><vspace blankLines="0" />
The cost of this route. Interpretation depends on the external
type indication (bit E above).</t>
<t hangText="PrefixLength, PrefixOptions and Address Prefix">
<vspace blankLines="0" />
Representation of the IPv6 address prefix, as described in Section
<xref target="prefix-rep"/>.</t>
<t hangText="Referenced LS Type"><vspace blankLines="0" />
If non-zero, an LSA with this LS type is to be associated with
this LSA (see Referenced Link State ID below).</t>
<t hangText="Forwarding address"><vspace blankLines="0" />
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
external prefix or may be obtained through some other
method (e.g., configuration).</t>
<t hangText="External Route Tag"><vspace blankLines="0" />
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.</t>
<t hangText="Referenced Link State ID"><vspace blankLines="0" />
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.</t>
</list></t>
<t>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.</t>
</section>
<section anchor="nssa-lsa-format" title="NSSA-LSAs">
<t>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 <xref target="NSSA" />). Other than
the LS Type, their format is exactly the same as AS-external LSAs
as described in <xref target="external-lsa-format"/>.</t>
<t>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 OSPF for
IPv4 <xref target="NSSA" /> only checking must be added to assure IPv6
link-local address are not selected.</t>
</section>
<section anchor="link-lsa-format" title="Link-LSAs">
<t>Link-LSAs have LS type equal to 0x0008. A router originates a
separate link-LSA for each attached physical link. These LSAs have
local-link flooding scope; they are never flooded beyond the associated link.
Link-LSAs have three purposes:
<vspace blankLines="1" /><list style="numbers">
<t>They provide the router's link-local address to all other routers
attached to the link.</t>
<t>They inform other routers attached to the link of a list of IPv6 prefixes
to associate with the link.</t>
<t>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.</t>
</list></t>
<t>For details concerning the construction of Links-LSAs,
see <xref target="link-lsa"/>.</t>
<t>A link-LSA's Link State ID is set equal to the originating router's
Interface ID on the link.
<figure title="Link LSA format">
<artwork>
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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<vspace blankLines="1" /><list style="hanging">
<t hangText="Rtr Priority"><vspace blankLines="0" />
The Router Priority of the interface attaching the originating
router to the link.</t>
<t hangText="Options"><vspace blankLines="0" />
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.</t>
<t hangText="Link-local Interface Address">
<vspace blankLines="0" />
The originating router's link-local interface address on the
link.</t>
<t hangText="# prefixes"><vspace blankLines="0" />
The number of IPv6 address prefixes contained in the LSA.</t>
</list></t>
<t>The rest of the link-LSA contains a list of IPv6 prefixes to be
associated with the link.
<vspace blankLines="1" /><list style="hanging">
<t hangText="PrefixLength, PrefixOptions and Address Prefix">
<vspace blankLines="0" />
Representation of an IPv6 address prefix, as described in
<xref target="prefix-rep"/></t>
</list></t>
</section>
<section anchor="intra-area-prefix-lsa-format" title="Intra-Area-Prefix-LSAs">
<t>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 <xref target="intra-area-prefix-lsa"/>.</t>
<t>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.
<figure title="intra-Area-Prefix LSA format">
<artwork>
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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<vspace blankLines="1" /><list style="hanging">
<t hangText="# prefixes"><vspace blankLines="0" />
The number of IPv6 address prefixes contained in the LSA.</t>
<t hangText="Referenced LS Type, Referenced Link State ID, and Referenced
Advertising Router"><vspace blankLines="0" />
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.</t>
</list></t>
<t>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.
<vspace blankLines="1" /><list style="hanging">
<t hangText="PrefixLength, PrefixOptions, and Address Prefix">
<vspace blankLines="0" />
Representation of an IPv6 address prefix, as described in Section
<xref target="prefix-rep"/></t>
<t hangText="Metric"><vspace blankLines="0" />
The cost of this prefix. Expressed in the same units as the
interface costs in router-LSAs.</t>
</list></t>
</section>
</section>
</section>
<section title="Architectural Constants">
<t>Architectural constants for the OSPF protocol are defined in Appendix
B of <xref target="OSPFV2"/>. The only difference for OSPF for IPv6 is that
DefaultDestination is encoded as a prefix with length 0 (see
<xref target="prefix-rep"/>).</t>
</section>
<section title="Configurable Constants">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<section anchor="global-config" title="Global parameters">
<t>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.
<vspace blankLines="1" /><list style="hanging">
<t hangText="Router ID"><vspace blankLines="0" />
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 <xref target="OSPFV2"/>). Otherwise, they will
persist for up to MaxAge seconds.</t>
</list></t>
<t>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).</t>
<t>The Router ID of 0.0.0.0 is reserved and SHOULD NOT be used.</t>
</section>
<section anchor="area-config" title="Area parameters">
<t>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:
<vspace blankLines="1" /><list style="hanging">
<t hangText="Area ID"><vspace blankLines="0" />
This is a 32-bit number that identifies the area. The Area
ID of 0 is reserved for the backbone.</t>
<t hangText="List of address ranges"><vspace blankLines="0" />
Address ranges control the advertisement of routes across
area boundaries. Each address range consists of the
following items:
<vspace blankLines="0" /><list style="hanging">
<t hangText="[IPv6 prefix, prefix length]">
<vspace blankLines="0" />
Describes the collection of IPv6 addresses contained in
the address range.</t>
<t hangText="Status"><vspace blankLines="0" />
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.</t>
</list></t>
<t hangText="ExternalRoutingCapability"><vspace blankLines="0" />
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 <xref target="OSPFV2"/> and
<xref target="NSSA"/>.</t>
<t hangText="StubDefaultCost"><vspace blankLines="0" />
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
<xref target="OSPFV2"/> for more information.</t>
<t hangText="NSSATranslatorRole and TranslatorStabilityInterval">
<vspace blankLines="0" />
These area parameters are described in Appendix D of
<xref target="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 <xref target="NSSA"/>.</t>
<t hangText="ImportSummaries">
<vspace blankLines="0" />
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.</t>
</list></t>
</section>
<section anchor="intf-config" title="Router interface parameters">
<t>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:
<vspace blankLines="1" /><list style="hanging">
<t hangText="IPv6 link-local address"><vspace blankLines="0" />
The IPv6 link-local address associated with this interface. May
be learned through auto-configuration.</t>
<t hangText="Area ID"><vspace blankLines="0" />
The OSPF area to which the attached link belongs.</t>
<t hangText="Instance ID"><vspace blankLines="0" />
The OSPF protocol instance associated with this OSPF interface.
Defaults to 0.</t>
<t hangText="Interface ID"><vspace blankLines="0" />
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
(<xref target="INTFMIB"/>).</t>
<t hangText="IPv6 prefixes"><vspace blankLines="0" />
The list of IPv6 prefixes to associate with the link. These will
be advertised in intra-area-prefix-LSAs.</t>
<t hangText="Interface output cost(s)"><vspace blankLines="0" />
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.</t>
<t hangText="RxmtInterval"><vspace blankLines="0" />
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.</t>
<t hangText="InfTransDelay"><vspace blankLines="0" />
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.</t>
<t hangText="Router Priority"><vspace blankLines="0" />
An 8-bit unsigned integer. When two routers attached to a network
both attempt to become Designated Router, the one with the highest
Router Priority takes precedence. If there is still a tie, the
router with the highest Router ID takes precedence. A router
whose Router Priority is set to 0 is ineligible to become
Designated Router on the attached link. Router Priority is only
configured for interfaces to broadcast and NBMA networks.</t>
<t hangText="HelloInterval"><vspace blankLines="0" />
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.</t>
<t hangText="RouterDeadInterval"><vspace blankLines="0" />
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.</t>
<t hangText="LinkLSASuppression"><vspace blankLines="0" />
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 <xref target="next-hop-calc"/>). 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.</t>
</list></t>
</section>
<section anchor="vl-parameters" title="Virtual link parameters">
<t>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.</t>
<t>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
<xref target="intf-config"/>). 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 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.</t>
<t>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 which 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).</t>
</section>
<section title="NBMA network parameters">
<t>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.</t>
<t>However, due to the lack of broadcast capabilities, it may be
necessary to use configuration parameters in the Designated Router
selection. These parameters will only need to be configured in those
routers that are themselves eligible to become Designated Router
(i.e., those router's whose Router Priority for the network is non-zero),
and then only if no automatic procedure for discovering neighbors exists:
<vspace blankLines="1" /><list style="hanging">
<t hangText="List of all other attached routers">
<vspace blankLines="0" />
The list of all other routers attached to the NBMA network. Each
router is configured with its Router ID and IPv6 link-local
address on the network. Also, for each router listed, that
router's eligibility to become Designated Router must be defined.
When an interface to an NBMA network first comes up, the router
only sends Hello packets to those neighbors eligible to become
Designated Router until such time that a Designated Router is
elected.</t>
<t hangText="PollInterval"><vspace blankLines="0" />
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.</t>
</list></t>
</section>
<section title="Point-to-Multipoint network parameters">
<t>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.</t>
</section>
<section anchor="host-config" title="Host route parameters">
<t>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:
<vspace blankLines="1" /><list style="hanging">
<t hangText="Host IPv6 prefix"><vspace blankLines="0" />
An IPv6 prefix belonging to the directly connected host. This
must not be a valid IPv6 global prefix.</t>
<t hangText="Cost of link to host"><vspace blankLines="0" />
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).</t>
<t hangText="Area ID"><vspace blankLines="0" />
The OSPF area to which the host's prefix belongs.</t>
</list></t>
</section>
</section>
<section title="Stub Area Unknown LSA Flooding Restriction Deprecated">
<t>In RFC 2740 <xref target="OSPFV3"/>, flooding of unknown LSA was restricted within stub
and NSSA areas.
The text describing this restriction is included below.
<figure title="Former Stub/NSSA Restriction">
<artwork>
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.
</artwork>
</figure></t>
<t>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.</t>
</section>
<section title="Change Log">
<section title="Changes from RFC 2740 to 00 Version">
<t>The section contains list of changes from RFC 2740 <xref target="OSPFV3" />:
<vspace blankLines="1" /><list style="symbols">
<t>Convert RFC 2740 text to XML format.</t>
<t>Convert all the references in the document to symbolic references and
correct the ones that were wrong.</t>
<t>Fix some selected typographical errors.</t>
<t>Remove references to the never-standardized
external attributes LSA.</t>
<t>Remove unreferenced or removed reference documents.</t>
</list></t>
</section>
<section title="Changes from the 00 Version to the 01 Version">
<t>The section contains list of changes from version 00 to
version 01:
<vspace blankLines="1" /><list style="symbols">
<t>Remove references to site-local addresses.</t>
<t>Correct link local range in <xref target="link-lsa"/>.</t>
<t>Clarify instance IDs on virtual links in
<xref target="multi-intf-instance"/> and
<xref target="vl-parameters"/>.</t>
<t>Clarify interface ID changes in <xref target="Orig-LSAs"/>.</t>
<t>Clarify unknown LSA type handling in Database Description packets in
<xref target="proto-receive"/>.</t>
<t>Clarify unknown LSA type handling in Link State Update packets in
<xref target="receive-lsu"/>.</t>
<t>Rewrite the confusing text regarding prefix inclusion in
<xref target="intra-area-prefix-lsa"/>.</t>
<t>Correct referenced LS types to the OSPFv3 types in
<xref target="intra-area-prefix-lsa"/>.</t>
<t>Indicate that transit links are ignored for routers that don't
have the V6 or R bits set in their router LSA options. See
<xref target="intra-spf"/>.</t>
<t>Correct field alignment in packet and LSA figures in Appendix A.</t>
<t>Clarify that a forwarding address should never be a link-local
address in <xref target="external-lsa-format"/>.</t>
<t>Added more information for NSSA support in
<xref target="ext-spf"/>,
<xref target="router-lsa-format"/>,
and <xref target="nssa-lsa-format"/>.</t>
<t>Added spacing before start of lists.</t>
</list></t>
</section>
<section title="Changes from the 01 Version to the 02 Version">
<t>The section contains list of changes from version 01 to
version 02:
<vspace blankLines="1" /><list style="symbols">
<t>Various typographical corrections.</t>
<t>Clarification of support for
multiple interfaces to a single link
(see <xref target="multi-intf"/>).</t>
</list></t>
</section>
<section title="Changes from the 02 Version to the 03 Version">
<t>The section contains list of changes from version 02 to
version 03:
<vspace blankLines="1" /><list style="symbols">
<t>Various typographical corrections.</t>
<t>Clarification of reorigination of LSAs when a neighbor's
interface ID changes (see <xref target="Orig-LSAs"/>).</t>
<t>Clarification of the significance of Interface Instance ID when
determining whether a router has multiple instances on the same
link (see <xref target="multi-intf"/>).</t>
<t>Fix the RFC 2119 reference RFC and date.</t>
<t>Add the DN bit to the options description since it will be published
as an RFC soon. Also reserve a bit for future OSPFv2 extensions.</t>
</list></t>
</section>
<section title="Changes from the 03 Version to the 04 Version">
<t>The section contains list of changes from version 03 to
version 04:
<vspace blankLines="1" /><list style="symbols">
<t>Various typographical corrections.</t>
<t>Link-LSAs are not needed on virtual links.</t>
<t>Capitalize MUST, MUST NOT, SHOULD, and MAY in places the usage
impacts protocol operation and interoperability.</t>
<t>Add reference to the IANA considerations document.</t>
</list></t>
</section>
<section title="Changes from the 04 Version to the 05 Version">
<t>The section contains list of changes from version 04 to
version 05:
<vspace blankLines="1" /><list style="symbols">
<t>Various typographical corrections.</t>
<t>Document that RFC1583Compatibility need not be considered
when calculating AS external routes in
<xref target="ext-spf"/>.</t>
<t>Clarify global IPv6 address advertisement for a forwarding
address in <xref target="external-lsa-format"/>.</t>
</list></t>
</section>
<section title="Changes from the 05 Version to the 06 Version">
<t>The section contains list of changes from version 05 to
version 06:
<vspace blankLines="1" /><list style="symbols">
<t>Move DN bit from LSA options to prefix options.</t>
<t>Remove the restriction on flooding unknown LSA types for
stub and NSSA areas. Refer to
<xref target="stub-nssa-support"/>.</t>
</list></t>
</section>
<section title="Changes from the 06 Version to the 07 Version">
<t>The section contains list of changes from version 06 to
version 07:
<vspace blankLines="1" /><list style="symbols">
<t>Mitchell Erblich's editorial comments.</t>
<t>Move LSA option processing into its own subsection
and make it applicable to all LSA types.
Refer to
<xref target="lsa-options"/>.</t>
</list></t>
</section>
<section title="Changes from the 07 Version to the 08 Version">
<t>The section contains list of changes from version 07 to
version 08:
<vspace blankLines="1" /><list style="symbols">
<t>Fix problem with vertex reference in the intra-area SPF
(see <xref target="intra-spf"/>).</t>
</list></t>
</section>
<section title="Changes from the 08 Version to the 09 Version">
<t>The section contains list of changes from version 08 to
version 09:
<vspace blankLines="1" /><list style="symbols">
<t>Additional clarifications to support for
multiple interfaces to a single link
(see <xref target="multi-intf"/>).</t>
<t>Document exception condition for multiple interfaces
to the same link in
(see <xref target="proto-receive"/>).</t>
<t>Remove reference to unnumbered link due to
the lack of applicability in IPv6
(see <xref target="vl-parameters"/>).</t>
</list></t>
</section>
<section title="Changes from the 09 Version to the 10 Version">
<t>The section contains list of changes from version 09 to
version 10:
<vspace blankLines="1" /><list style="symbols">
<t>Russ White's editorial comments.</t>
<t>Correct discussion of interface ID versus interface Instance ID
on virtual links in
(see <xref target="intf-data-struct"/>).</t>
<t>Changes to protocol packet reception in support of multiple
interfaces on the same link and the interface configured with
multiple Instance IDs (see <xref target="proto-receive"/>).</t>
<t>Add note describing reorigination of network-LSAs in the case where
the logical OR of LSA options for routers on the link changes
(see <xref target="Orig-LSAs"/>).</t>
<t>Reword the section on Active Interface failure detection to allow
for some flexibility (see <xref target="multi-intf"/>).</t>
<t>Add the LinkLSASuppression interface configuration parameter as
described in <xref target="intf-config"/>. Also updated
<xref target="next-hop-calc"/> and
<xref target="link-lsa"/> to reflect the parameter's use.</t>
<t>Clarify advertisement of LA-bit set prefixes in intra-area-prefix-LSAs
associated with a router <xref target="intra-area-prefix-lsa"/>.</t>
</list></t>
</section>
<section title="Changes from the 10 Version to the 11 Version">
<t>The section contains list of changes from version 10 to
version 11:
<vspace blankLines="1" /><list style="symbols">
<t>Fix spelling of Manoj Goyal's name in the acknowledgments.</t>
<t>Add statement regarding alternate algorithms and optimizations to
<xref target="intra-spf"/>.</t>
</list></t>
</section>
<section title="Changes from the 11 Version to the 12 Version">
<t>The section contains list of changes from version 11 to
version 12:
<vspace blankLines="1" /><list style="symbols">
<t>A couple spelling errors.</t>
<t>Add statement indicating that routers that originate AS externally
scoped LSAs are ASBRs to <xref target="flood-scope"/>.</t>
<t>Add reference to RFC 4552 for OSPFv3 Authentication/Confidentiality.</t>
<t>Remove reference to RFC 1745 since it is historic.</t>
<t>Fix reference for DN-Bit to point to new RFC 4576.</t>
<t>Added <xref target="new-lsa"/> to discuss validation of
future LSAs.</t>
</list></t>
</section>
<section title="Changes from the 12 Version to the 13 Version">
<t>The section contains list of changes from version 12 to
version 13:
<vspace blankLines="1" /><list style="symbols">
<t>Fixed Rob Coltun's contact information.</t>
<t>Made capitalization for OSPF packet types consistent. The proper
packet type, e.g. Hello, will be capitalized while the word "packet" will
not unless it is part of a section title.</t>
</list></t>
</section>
<section title="Changes from the 13 Version to the 14 Version">
<t>The section contains list of changes from version 13 to
version 14:
<vspace blankLines="1" /><list style="symbols">
<t>Add missing NSSA-LSA section <xref target="NSSA"/>.</t>
<t>Numerous editorial changes. For example, consistent capitalization of
"Instance ID".</t>
<t>Some clarifications in handling of multiple interfaces to a single
line (see <xref target="multi-intf"/>).</t>
<t>Remove vestige of the stub and NSSA area unknown LSA type flooding restriction
in <xref target="receive-lsu"/>.</t>
<t>Remove confusing paragraph in the Security Considerations
(see <xref target="security"/>) since we now
have <xref target="OSPFV3-AUTH"/> to deal comprehensively with OSPFv3 security.</t>
<t>Update the editor's contact information.</t>
</list></t>
</section>
<section title="Changes from the 14 Version to the 15 Version">
<t>The section contains list of changes from version 14 to
version 15:
<vspace blankLines="1" /><list style="symbols">
<t>Clarification of the next-hop calculation for directly connected transit networks.
Refer to <xref target="next-hop-calc"/>.</t>
</list></t>
</section>
<section title="Changes from the 15 Version to the 16 Version">
<t>The section contains list of changes from version 15 to
version 16:
<vspace blankLines="1" /><list style="symbols">
<t>Add new prefix options and options field bits added in this document to
the IANA considerations. Refer to <xref target="iana"/>.</t>
</list></t>
</section>
<section title="Changes from the 16 Version to the 17 Version">
<t>The section contains list of changes from version 16 to
version 17:
<vspace blankLines="1" /><list style="symbols">
<t>Changes to deprecate MOSPF for OSPFv3.
Refer to <xref target="router-lsa"/>,
<xref target="inter-area-prefix-lsa"/>,
<xref target="external-lsa"/>, <xref target="nssa-lsa"/>,
<xref target="options-field"/>, <xref target="lsa-type"/>,
and <xref target="router-lsa-format"/>.</t>
<t>Deprecate the MC-bit
in the prefix options which was never adequated specified.
Refer to <xref target="prefix-options"/>.</t>
<t>The corresponding IANA actions for MOSPF for OSPFv3 depracation. Refer to
<xref target="iana-mospf-deprecation"/>.</t>
<t>Clarify the setting of the options in the network-LSA.
Refer to <xref target="network-lsa-format"/>.</t>
</list></t>
</section>
<section title="Changes from the 17 Version to the 18 Version">
<t>The section contains list of changes from version 17 to
version 18:
<vspace blankLines="1" /><list style="symbols">
<t>Fix reference to <xref target="receive-lsu"/>
in <xref target="proto-receive"/>.</t>
<t>Add text about mapping precedence to traffic class to
<xref target="encap"/>.</t>
</list></t>
</section>
<section title="Changes from the 18 Version to the 19 Version">
<t>The section contains list of changes from version 18 to
version 19:
<vspace blankLines="1" /><list style="symbols">
<t>Change LSA type to 0x2005 in <xref target="nssa-lsa"/>.</t>
<t>Remove a reference to the W-bit from <xref target="intra-spf"/>.</t>
<t>Add W-bit deprecation and new OSPFv3 Router Properties registry to
<xref target="iana-mospf-deprecation"/>.</t>
</list></t>
</section>
<section title="Changes from the 19 Version to the 20 Version">
<t>The section contains list of changes from version 19 to
version 20:
<vspace blankLines="1" /><list style="symbols">
<t>Add clarification to the IANA considerations that this document
will replace RFC 2740 (see <xref target="iana"/>).</t>
</list></t>
</section>
<section title="Changes from the 20 Version to the 21 Version">
<t>The section contains list of changes from version 20 to
version 21:
<vspace blankLines="1" /><list style="symbols">
<t>Update the Abstract and Introduction to be clear that the intend of
the document is to describe a separate vesion of OSPF.</t>
<t>Expand some acronyms prior to their first use.</t>
<t>Update normative references to latest RFCs.</t>
<t>Change IPv4 and IPv6 addresses to the example address in RFC 3330 and RFC 3849.</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:20:45 |