RFC relevance of designated

As per Relevance of the word designated, we have this rfc below:

Network Working Group R.
Requests for Comments: 2740 Siara
Category: Standards Track D.
Juniper
J.
Sycamore
December 1999

OSPF for IPv

Status of this

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

Copyright

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

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

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

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

Coltun, et al. Standards Track [Page 1]

RFC 2740 OSPF for IPv6 December 1999

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

Table of

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

Coltun, et al. Standards Track [Page 2]

RFC 2740 OSPF for IPv6 December 1999

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

Coltun, et al. Standards Track [Page 3]

RFC 2740 OSPF for IPv6 December 1999

1.

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

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

1.1.

This document attempts to use terms from both the OSPF for IPv
specification ([Ref1]) and the IPv6 protocol
([Ref14]). This has produced a mixed result. Most of the terms
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
chosen to use IPv6's "link" terminology. "Link" replaces OSPF'
"subnet" and "network" in most places in this document,
OSPF's Network-LSA remains unchanged (and possibly unfortunately,
new Link-LSA has also been created).

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

2. Differences from OSPF for IPv

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

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

Coltun, et al. Standards Track [Page 4]

RFC 2740 OSPF for IPv6 December 1999

2.1. Protocol processing per-link, not per-

IPv6 uses the term "link" to indicate "a communication facility
medium over which nodes can communicate at the link layer" ([Ref14]).
"Interfaces" connect to links. Multiple IP subnets can be assigned
a single link, and two nodes can talk directly over a single link
even if they do not share a common IP subnet (IPv6 prefix).

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

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

2.2. Removal of addressing

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

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

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

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

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

2.3. Addition of Flooding

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

Coltun, et al. Standards Track [Page 5]

RFC 2740 OSPF for IPv6 December 1999

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

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

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

2.4. Explicit support for multiple instances per

OSPF now supports the ability to run multiple OSPF protocol
on a single link. For example, this may be required on a NAP
shared between several providers -- providers may be running
OSPF routing domains that want to remain separate even though
have one or more physical network segments (i.e., links) in common
In OSPF for IPv4 this was supported in a haphazard fashion using
authentication fields in the OSPF for IPv4 header

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

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

2.5. Use of link-local

IPv6 link-local addresses are for use on a single link, for
of neighbor discovery, auto-configuration, etc. IPv6 routers do
forward IPv6 datagrams having link-local source addresses [Ref15].
Link-local unicast addresses are assigned from the IPv6 address
FF80/10.

OSPF for IPv6 assumes that each router has been assigned link-
unicast addresses on each of the router's attached physical segments
On all OSPF interfaces except virtual links, OSPF packets are
using the interface's associated link-local unicast address
source. A router learns the link-local addresses of all
routers attached to its links, and uses these addresses as next
information during packet forwarding

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

Coltun, et al. Standards Track [Page 6]

RFC 2740 OSPF for IPv6 December 1999

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

2.6. Authentication

In OSPF for IPv6, authentication has been removed from OSPF itself
The "AuType" and "Authentication" fields have been removed from
OSPF packet header, and all authentication related fields have
removed from the OSPF area and interface structures

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

Protection of OSPF packet exchanges against accidental
corruption is provided by the standard IPv6 16-bit one's
checksum, covering the entire OSPF packet and prepended IPv6 pseudo
header (see Section A.3.1).

2.7. Packet format

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

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

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

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

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

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

Coltun, et al. Standards Track [Page 7]

RFC 2740 OSPF for IPv6 December 1999

o Two option bits, the "R-bit" and the "V6-bit", have been added
the Options field for processing Router-LSAs during the
calculation (see Section A.2). If the "R-bit" is clear an
speaker can participate in OSPF topology distribution
being used to forward transit traffic; this can be used in multi
homed hosts that want to participate in the routing protocol.
V6-bit specializes the R-bit; if the V6-bit is clear an
speaker can participate in OSPF topology distribution
being used to forward IPv6 datagrams. If the R-bit is set and
V6-bit is clear, IPv6 datagrams are not forwarded but
belonging to another protocol family may be forwarded

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

2.8. LSA format

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

In detail, changes in LSA format consist of the following

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

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

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

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

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

Coltun, et al. Standards Track [Page 8]

RFC 2740 OSPF for IPv6 December 1999

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

In IPv4, the router-LSA carries a router's IPv4
addresses, the IPv4 equivalent of link-local addresses. These
only used when calculating next hops during the OSPF
calculation (see Section 16.1.1 of [Ref1]), so they do not need
be flooded past the local link; hence using link-LSAs
distribute these addresses is more efficient. Note that link-
addresses cannot be learned through the reception of Hellos in
cases: on NBMA links next hop routers do not necessarily
hellos, but rather learn of each other's existence by way of
Designated Router

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

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

o The Link State ID in Inter-Area-Prefix-LSAs, Inter-Area-Router
LSAs and AS-external-LSAs has lost its addressing semantics,
now serves solely to identify individual pieces of the Link
Database. All addresses or Router IDs that were formerly
by the Link State ID are now carried in the LSA bodies

o Network-LSAs and Link-LSAs are the only LSAs whose Link State
carries additional meaning. For these LSAs, the Link State ID
always the Interface ID of the originating router on the
being described. For this reason, Network-LSAs and Link-LSAs
now the only LSAs whose size cannot be limited: a Network-LSA
list all routers connected to the link, and a Link-LSA must
all of a router's addresses on the link

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

Coltun, et al. Standards Track [Page 9]

RFC 2740 OSPF for IPv6 December 1999

o Inclusion of a forwarding address in AS-external-LSAs is
optional, as is the inclusion of an external route tag (
[Ref5]). In addition, AS-external-LSAs can now reference
LSA, for inclusion of additional route attributes that are
the scope of the OSPF protocol itself. For example, this can
used to attach BGP path attributes to external routes as
in [Ref10].

2.9. Handling unknown LSA

Handling of unknown LSA types has been made more flexible so that
based on LS type, unknown LSA types are either treated as
link-local flooding scope, or are stored and flooded as if they
understood (desirable for things like the proposed External
Attributes-LSA in [Ref10]). This behavior is explicitly coded in
LSA Handling bit of the link state header's LS type field (
Section A.4.2.1).

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

2.10. Stub area

In OSPF for IPv4, stub areas were designed to minimize link-
database and routing table sizes for the areas' internal routers
This allows routers with minimal resources to participate in
very large OSPF routing domains

In OSPF for IPv6, the concept of stub areas is retained. In IPv6,
the mandatory LSA types, stub areas carry only router-LSAs, network
LSAs, Inter-Area-Prefix-LSAs, Link-LSAs, and Intra-Area-Prefix-LSAs
This is the IPv6 equivalent of the LSA types carried in IPv4
areas: router-LSAs, network-LSAs and type 3 summary-LSAs

However, unlike in IPv4, IPv6 allows LSAs with unrecognized LS
to be labeled "Store and flood the LSA, as if type understood" (
the U-bit in Section A.4.2.1). Uncontrolled introduction of such
could cause a stub area's link-state database to grow larger than
component routers' capacities

To guard against this, the following rule regarding stub areas
been established: an LSA whose LS type is unrecognized may only
flooded into/throughout a stub area if both a) the LSA has area
link-local flooding scope and b) the LSA has U-bit set to 0.
Section 3.5 for details

Coltun, et al. Standards Track [Page 10]

RFC 2740 OSPF for IPv6 December 1999

2.11. Identifying neighbors by Router

In OSPF for IPv6, neighboring routers on a given link are
identified by their OSPF Router ID. This contrasts with the IPv
behavior where neighbors on point-to-point networks and virtual
are identified by their Router IDs, and neighbors on broadcast,
and Point-to-MultiPoint links are identified by their IPv4
addresses

This change affects the reception of OSPF packets (see Section 8.2
[Ref1]), the lookup of neighbors (Section 10 of [Ref1]) and
reception of Hello Packets (Section 10.5 of [Ref1]).

The Router ID of 0.0.0.0 is reserved, and should not be used

3. Implementation

When going from IPv4 to IPv6, the basic OSPF mechanisms
unchanged from those documented in [Ref1]. These mechanisms
briefly outlined in Section 4 of [Ref1]. Both IPv6 and IPv4 have
link-state database composed of LSAs and synchronized
adjacent routers. Initial synchronization is performed through
Database Exchange process, through the exchange of
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
neighbor relationships, and to elect Designated Routers and
Designated Routers on broadcast and NBMA links. The decision as
which neighbor relationships become adjacencies, along with the
ideas behind inter-area routing, importing external information
AS-external-LSAs and the various routing calculations are also
same

In particular, the following IPv4 OSPF functionality described
[Ref1] remains completely unchanged for IPv6:

o Both IPv4 and IPv6 use OSPF packet types described in Section 4.3
of [Ref1], namely: Hello, Database Description, Link
Request, Link State Update and Link State Acknowledgment packets
While in some cases (e.g., Hello packets) their format has
somewhat, the functions of the various packet types remains
same

o The system requirements for an OSPF implementation
unchanged, although OSPF for IPv6 requires an IPv6 protocol
(from the network layer on down) since it runs directly over
IPv6 network layer

Coltun, et al. Standards Track [Page 11]

RFC 2740 OSPF for IPv6 December 1999

o The discovery and maintenance of neighbor relationships, and
selection and establishment of adjacencies remain the same.
includes election of the Designated Router and Backup
Router on broadcast and NBMA links. These mechanisms are
in Sections 7, 7.1, 7.2, 7.3, 7.4 and 7.5 of [Ref1].

o The link types (or equivalently, interface types) supported
OSPF remain unchanged, namely: point-to-point, broadcast, NBMA
Point-to-MultiPoint and virtual links

o The interface state machine, including the list of OSPF
states and events, and the Designated Router and Backup
Router election algorithm, remain unchanged. These are
in Sections 9.1, 9.2, 9.3 and 9.4 of [Ref1].

o The neighbor state machine, including the list of OSPF
states and events, remain unchanged. These are described
Sections 10.1, 10.2, 10.3 and 10.4 of [Ref1].

o Aging of the link-state database, as well as flushing LSAs
the routing domain through the premature aging process,
unchanged from the description in Sections 14 and 14.1 of [Ref1].

However, some OSPF protocol mechanisms have changed, as outlined
Section 2 above. These changes are explained in detail in
following subsections, making references to the appropriate
of [Ref1].

The following subsections provide a recipe for turning an IPv4
implementation into an IPv6 OSPF implementation

3.1. Protocol data

The major OSPF data structures are the same for both IPv4 and IPv6:
areas, interfaces, neighbors, the link-state database and the
table. The top-level data structures for IPv6 remain those listed
Section 5 of [Ref1], with the following modifications

o All LSAs with known LS type and AS flooding scope appear in
top-level data structure, instead of belonging to a specific
or link. AS-external-LSAs are the only LSAs defined by
specification which have AS flooding scope. LSAs with unknown
type, U-bit set to 1 (flood even when unrecognized) and
flooding scope also appear in the top-level data structure

Coltun, et al. Standards Track [Page 12]

RFC 2740 OSPF for IPv6 December 1999

3.1.1. The Area Data

The IPv6 area data structure contains all elements defined for IPv
areas in Section 6 of [Ref1]. In addition, all LSAs of known
which have area flooding scope are contained in the IPv6 area
structure. This always includes the following LSA types: router-LSAs
network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs
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
data structure. IPv6 routers implementing MOSPF add group
membership-LSAs to the area data structure. Type-7-LSAs belong to
NSSA area's data structure

3.1.2. The Interface Data

In OSPF for IPv6, an interface connects a router to a link. The IPv
interface structure modifies the IPv4 interface structure (as
in Section 9 of [Ref1]) as follows

Interface
Every interface is assigned an Interface ID, which
identifies the interface with the router. For example,
implementations may be able to use the MIB-II IfIndex ([Ref3])
Interface ID. The Interface ID appears in Hello packets sent
the interface, the link-local-LSA originated by router for
attached link, and the router-LSA originated by the router-LSA
the associated area. It will also serve as the Link State ID
the network-LSA that the router will originate for the link if
router is elected Designated Router

Instance
Every interface is assigned an Instance ID. This should default
0, and is only necessary to assign differently on those links
will contain multiple separate communities of OSPF Routers.
example, suppose that there are two communities of routers on
given ethernet segment that you wish to keep separate

The first community is given an Instance ID of 0, by assigning 0
as the Instance ID of all its routers' interfaces to the ethernet
An Instance ID of 1 is assigned to the other routers'
to the ethernet. The OSPF transmit and receive processing (
Section 3.2) will then keep the two communities separate

List of LSAs with link-local
All LSAs with link-local scope and which were originated/
on the link belong to the interface structure which connects
the link. This includes the collection of the link's link-LSAs

Coltun, et al. Standards Track [Page 13]

RFC 2740 OSPF for IPv6 December 1999

List of LSAs with unknown LS
All LSAs with unknown LS type and U-bit set to 0 (if unrecognized
treat the LSA as if it had link-local flooding scope) are kept
the data structure for the interface that received the LSA

IP interface
For IPv6, the IPv6 address appearing in the source of OSPF
sent out the interface is almost always a link-local address.
one exception is for virtual links, which must use one of
router's own site-local or global IPv6 addresses as IP
address

List of link
A list of IPv6 prefixes can be configured for the attached link
These will be advertised by the router in link-LSAs, so that
can be advertised by the link's Designated Router in intra-area
prefix-LSAs

In OSPF for IPv6, each router interface has a single metric
representing the cost of sending packets out the interface.
addition, OSPF for IPv6 relies on the IP Authentication Header (
[Ref19]) and the IP Encapsulating Security Payload (see [Ref20])
ensure integrity and authentication/confidentiality of
exchanges. For that reason, AuType and Authentication key are
associated with IPv6 OSPF interfaces

Interface states, events, and the interface state machine
unchanged from IPv4, and are documented in Sections 9.1, 9.2 and 9.3
of [Ref1] respectively. The Designated Router and Backup
Router election algorithm also remains unchanged from the IPv
election in Section 9.4 of [Ref1].

3.1.3. The Neighbor Data

The neighbor structure performs the same function in both IPv6
IPv4. Namely, it collects all information required to form
adjacency between two routers, if an adjacency becomes necessary
Each neighbor structure is bound to a single OSPF interface.
differences between the IPv6 neighbor structure and the
structure defined for IPv4 in Section 10 of [Ref1] are

Neighbor's Interface
The Interface ID that the neighbor advertises in its Hello
must be recorded in the neighbor structure. The router
include the neighbor's Interface ID in the router's router-
when either a) advertising a point-to-point link to the
or b) advertising a link to a network where the neighbor
become Designated Router

Coltun, et al. Standards Track [Page 14]

RFC 2740 OSPF for IPv6 December 1999

Neighbor IP
Except on virtual links, the neighbor's IP address will be an IPv
link-local address

Neighbor's Designated
The neighbor's choice of Designated Router is now encoded as
Router ID, instead of as an IP address

Neighbor's Backup Designated
The neighbor's choice of Designated Router is now encoded as
Router ID, instead of as an IP address

Neighbor states, events, and the neighbor state machine
unchanged from IPv4, and are documented in Sections 10.1, 10.2
10.3 of [Ref1] respectively. The decision as to which adjacencies
form also remains unchanged from the IPv4 logic documented in
10.4 of [Ref1].

3.2. Protocol Packet

OSPF for IPv6 runs directly over IPv6's network layer. As such, it
encapsulated in one or more IPv6 headers, with the Next Header
of the immediately encapsulating IPv6 header set to the value 89.

As for IPv4, in IPv6 OSPF routing protocol packets are sent
adjacencies only (with the exception of Hello packets, which are
to discover the adjacencies). OSPF packet types and functions are
same in both IPv4 and IPv4, encoded by

Type field of the standard OSPF packet header

3.2.1. Sending protocol

When an IPv6 router sends an OSPF routing protocol packet, it
in the fields of the standard OSPF for IPv6 packet header (
Section A.3.1) as follows

Version #
Set to 3, the version number of the protocol as documented in
specification

The type of OSPF packet, such as Link state Update or
Packet

Packet
The length of the entire OSPF packet in bytes, including
standard OSPF packet header

Coltun, et al. Standards Track [Page 15]

RFC 2740 OSPF for IPv6 December 1999

Router
The identity of the router itself (who is originating the packet).

Area
The OSPF area that the packet is being sent into

Instance
The OSPF Instance ID associated with the interface that the
is being sent out of

The standard IPv6 16-bit one's complement checksum, covering
entire OSPF packet and prepended IPv6 pseudo-header (see
A.3.1).

Selection of OSPF routing protocol packets' IPv6 source
destination addresses is performed identically to the IPv4 logic
Section 8.1 of [Ref1]. The IPv6 destination address is chosen
among the addresses AllSPFRouters, AllDRouters and the Neighbor
address associated with the other end of the adjacency (which
IPv6, for all links except virtual links, is an IPv6 link-
address).

The sending of Link State Request Packets and Link
Acknowledgment Packets remains unchanged from the IPv4
documented in Sections 10.9 and 13.5 of [Ref1] respectively.
Hello Packets is documented in Section 3.2.1.1, and the sending
Database Description Packets in Section 3.2.1.2. The sending of
State Update Packets is documented in Section 3.5.2.

3.2.1.1. Sending Hello

IPv6 changes the way OSPF Hello packets are sent in the
ways (compare to Section 9.5 of [Ref1]):

o Before the Hello Packet is sent out an interface, the interface'
Interface ID must be copied into the Hello Packet

o The Hello Packet no longer contains an IP network mask, as
for IPv6 runs per-link instead of per-subnet

o The choice of Designated Router and Backup Designated Router
now indicated within Hellos by their Router IDs, instead of
their IP interface addresses. Advertising the
Router (or Backup Designated Router) as 0.0.0.0 indicates that
Designated Router (or Backup Designated Router) has not yet
chosen

Coltun, et al. Standards Track [Page 16]

RFC 2740 OSPF for IPv6 December 1999

o The Options field within Hello packets has moved around,
larger in the process. More options bits are now possible.
that must be set correctly in Hello packets are: The E-bit is
if and only if the interface attaches to a non-stub area, the N
bit is set if and only if the interface attaches to an NSSA
(see [Ref9]), and the DC- bit is set if and only if the
wishes to suppress the sending of future Hellos over the
(see [Ref11]). Unrecognized bits in the Hello Packet's
field should be cleared

Sending Hello packets on NBMA networks proceeds for IPv6 in
the same way as for IPv4, as documented in Section 9.5.1 of [Ref1].

3.2.1.2. Sending Database Description

The sending of Database Description packets differs from Section 10.8
of [Ref1] in the following ways

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

3.2.2. Receiving protocol

Whenever an OSPF protocol packet is received by the router it
marked with the interface it was received on. For routers that
virtual links configured, it may not be immediately obvious
interface to associate the packet with. For example, consider
Router RT11 depicted in Figure 6 of [Ref1]. If RT11 receives an
protocol packet on its interface to Network N8, it may want
associate the packet with the interface to Area 2, or with
virtual link to Router RT10 (which is part of the backbone).
the following, we assume that the packet is initially associated
the non-virtual link

In order for the packet to be passed to OSPF for processing,
following tests must be performed on the encapsulating IPv6 headers

o The packet's IP destination address must be one of the IPv
unicast addresses associated with the receiving interface (
includes link-local addresses), or one of the IP
addresses AllSPFRouters or AllDRouters

Coltun, et al. Standards Track [Page 17]

RFC 2740 OSPF for IPv6 December 1999

o The Next Header field of the immediately encapsulating IPv6
must specify the OSPF protocol (89).

o Any encapsulating IP Authentication Headers (see [Ref19]) and
IP Encapsulating Security Payloads (see [Ref20]) must be
and/or verified to ensure integrity
authentication/confidentiality of OSPF routing exchanges

o Locally originated packets should not be passed on to OSPF.
is, the source IPv6 address should be examined to make sure
is not a multicast packet that the router itself generated

After processing the encapsulating IPv6 headers, the OSPF
header is processed. The fields specified in the header must
those configured for the receiving interface. If they do not,
packet should be discarded

o The version number field must specify protocol version 3.

o The standard IPv6 16-bit one's complement checksum, covering
entire OSPF packet and prepended IPv6 pseudo-header, must
verified (see Section A.3.1).

o The Area ID found in the OSPF header must be verified. If both
the following cases fail, the packet should be discarded.
Area ID specified in the header must either

(1) Match the Area ID of the receiving interface.
this case, unlike for IPv4, the IPv6
address is not restricted to lie on the same
subnet as the receiving interface. IPv6 OSPF
per-link, instead of per-IP-subnet

(2) Indicate the backbone. In this case, the
has been sent over a virtual link. The
router must be an area border router, and
Router ID specified in the packet (the
router) must be the other end of a
virtual link. The receiving interface must
attach to the virtual link's configured
area. If all of these checks succeed, the
is accepted and is from now on associated
the virtual link (and the backbone area).

o The Instance ID specified in the OSPF header must match
receiving interface's Instance ID

Coltun, et al. Standards Track [Page 18]

RFC 2740 OSPF for IPv6 December 1999

o Packets whose IP destination is AllDRouters should only
accepted if the state of the receiving interface is DR or
(see Section 9.1).

After header processing, the packet is further processed according
its OSPF packet type. OSPF packet types and functions are the
for both IPv4 and IPv6.

If the packet type is Hello, it should then be further processed
the Hello Protocol. All other packet types are sent/received only
adjacencies. This means that the packet must have been sent by
of the router's active neighbors. The neighbor is identified by
Router ID appearing the the received packet's OSPF header.
not matching any active neighbor are discarded

The receive processing of Database Description Packets, Link
Request Packets and Link State Acknowledgment Packets
unchanged from the IPv4 procedures documented in Sections 10.6, 10.7
and 13.7 of [Ref1] respectively. The receiving of Hello Packets
documented in Section 3.2.2.1, and the receiving of Link State
Packets is documented in Section 3.5.1.

3.2.2.1. Receiving Hello

The receive processing of Hello Packets differs from Section 10.5
[Ref1] in the following ways

o On all link types (e.g., broadcast, NBMA, point-to- point, etc),
neighbors are identified solely by their OSPF Router ID. For
link types except virtual links, the Neighbor IP address is set
the IPv6 source address in the IPv6 header of the received
Hello packet

o There is no longer a Network Mask field in the Hello Packet

o The neighbor's choice of Designated Router and Backup
Router is now encoded as an OSPF Router ID instead of an
interface address

3.3. The Routing table

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

Coltun, et al. Standards Track [Page 19]

RFC 2740 OSPF for IPv6 December 1999

Also, to hold the intermediate results during the shortest-
calculation for each area, there is a separate routing table for
area holding the following entries

o An entry for each router in the area. Routers are identified
their OSPF router ID. These routing table entries hold the set
shortest paths through a given area to a given router, which
turn allows calculation of paths to the IPv6 prefixes
by that router in Intra-area-prefix-LSAs. If the router is also
area-border router, these entries are also used to calculate
for inter-area address prefixes. If in addition the router is
other endpoint of a virtual link, the routing table
describes the cost and viability of the virtual link

o An entry for each transit link in the area. Transit links
associated network-LSAs. Both the transit link and the network-
are identified by a combination of the Designated Router'
Interface ID on the link and the Designated Router's OSPF
ID. These routing table entries allow later calculation of
to IP prefixes advertised for the transit link in intra-area
prefix-LSAs

The fields in the IPv4 OSPF routing table (see Section 11 of [Ref1])
remain valid for IPv6: Optional capabilities (routers only),
type, cost, type 2 cost, link state origin, and for each of the
cost paths to the destination, the next hop and advertising router

For IPv6, the link-state origin field in the routing table entry
the router-LSA or network-LSA that has directly or
produced the routing table entry. For example, if the routing
entry describes a route to an IPv6 prefix, the link state origin
the router-LSA or network-LSA that is listed in the body of
intra-area-prefix-LSA that has produced the route (see
A.4.9).

3.3.1. Routing table

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

3.4. Link State

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

Coltun, et al. Standards Track [Page 20]

RFC 2740 OSPF for IPv6 December 1999

LSAs respectively) and additional LSAs have been added (Link-LSAs
Intra-Area-Prefix-LSAs). Type of Service (TOS) has been removed
the OSPFv2 specification [Ref1], and is not encoded within OSPF
IPv6's LSAs

These changes will be described in detail in the
subsections

3.4.1. The LSA

In both IPv4 and IPv6, all OSPF LSAs begin with a standard 20
LSA header. However, the contents of this 20 byte header have
in IPv6. The LS age, Advertising Router, LS Sequence Number,
checksum and length fields within the LSA header remain unchanged,
documented in Sections 12.1.1, 12.1.5, 12.1.6, 12.1.7 and A.4.1
[Ref1] respectively. However, the following fields have changed
IPv6:

The Options field has been removed from the standard 20 byte
header, and into the body of router-LSAs, network-LSAs, inter
area-router-LSAs and link-LSAs. The size of the Options field
increased from 8 to 24 bits, and some of the bit definitions
changed (see Section A.2). In addition a separate
field, 8 bits in length, is attached to each prefix
within the body of an LSA

LS
The size of the LS type field has increased from 8 to 16 bits
with the top two bits encoding flooding scope and the next
encoding the handling of unknown LS types. See Section A.4.2.1
for the current coding of the LS type field

Link State
Link State ID remains at 32 bits in length, but except
network-LSAs and link-LSAs, Link State ID has shed any
semantics. For example, an IPv6 router originating multiple AS
external-LSAs could start by assigning the first a Link State
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
the AS-external-LSA's Link State ID, the IPv6 Link State ID
serves as a way to differentiate multiple LSAs originated by
same router

For network-LSAs, the Link State ID is set to the
Router's Interface ID on the link. When a router originates
Link-LSA for a given link, its Link State ID is set equal to
router's Interface ID on the link

Coltun, et al. Standards Track [Page 21]

RFC 2740 OSPF for IPv6 December 1999

3.4.2. The link-state

In IPv6, as in IPv4, individual LSAs are identified by a
of their LS type, Link State ID and Advertising Router fields.
two instances of an LSA, the most recent instance is determined
examining the LSAs' LS Sequence Number, using LS checksum and LS
as tiebreakers (see Section 13.1 of [Ref1]).

In IPv6, the link-state database is split across three separate
structures. LSAs with AS flooding scope are contained within
top-level OSPF data structure (see Section 3.1) as long as
their LS type is known or their U-bit is 1 (flood even
unrecognized); this includes the AS-external-LSAs. LSAs with
flooding scope are contained within the appropriate area
(see Section 3.1.1) as long as either their LS type is known or
U-bit is 1 (flood even when unrecognized); this includes router-LSAs
network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs,
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
interface structure (see Section 3.1.2); this includes link-LSAs

To lookup or install an LSA in the database, you first examine the
type and the LSA's context (i.e., to which area or link does the
belong). This information allows you to find the correct list
LSAs, all of the same LS type, where you then search based on
LSA's Link State ID and Advertising Router

3.4.3. Originating

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
database and flooded out the appropriate interfaces

To the list of events causing LSAs to be reoriginated, which for IPv
is given in Section 12.4 of [Ref1], the following events and/
actions are added for IPv6:

o The state of one of the router's interfaces changes. The
may need to (re)originate or flush its Link-LSA and one or
router-LSAs and/or intra-area-prefix-LSAs

o The identity of a link's Designated Router changes. The router
need to (re)originate or flush the link's network-LSA and one
more router-LSAs and/or intra-area-prefix-LSAs

Coltun, et al. Standards Track [Page 22]

RFC 2740 OSPF for IPv6 December 1999

o A neighbor transitions to/from "Full" state. The router may
to (re)originate or flush the link's network-LSA and one or
router-LSAs and/or intra-area-prefix-LSAs

o The Interface ID of a neighbor changes. This may cause a
instance of a router-LSA to be originated for the associated area
and the reorigination of one or more intra-area-prefix-LSAs

o A new prefix is added to an attached link, or a prefix is
(both through configuration). This causes the router
reoriginate its link-LSA for the link, or, if it is the
router attached to the link, causes the router to reoriginate
intra-area-prefix-LSA

o A new link-LSA is received, causing the link's collection
prefixes to change. If the router is Designated Router for
link, it originates a new intra-area-prefix-LSA

Detailed construction of the seven required IPv6 LSA types
supplied by the following subsections. In order to display
LSAs, the network map in Figure 15 of [Ref1] has been reworked
show IPv6 addressing, resulting in Figure 1. The OSPF cost of
interface is has been displayed in Figure 1. The assignment of IPv
prefixes to network links is shown in Table 1. A single area
range has been configured for Area 1, so that outside of Area 1
of its prefixes are covered by a single route to 5f00:0000:c001::/48.
The OSPF interface IDs and the link-local addresses for the
interfaces in Figure 1 are given in Table 2.

Coltun, et al. Standards Track [Page 23]

RFC 2740 OSPF for IPv6 December 1999

..........................................
. Area 1.
. + .
. | .
. | 3+---+1 .
. N1 |--|RT1|-----+ .
. | +---+ \ .
. | \ ______ .
. + \/ \ 1+---+
. * N3 *------|RT4|------
. + /\_______/ +---+
. | / | .
. | 3+---+1 / | .
. N2 |--|RT2|-----+ 1| .
. | +---+ +---+ .
. | |RT3|----------------
. + +---+ .
. |2 .
. | .
. +------------+ .
. N4 .
..........................................

Figure 1: Area 1 with IP addresses

Network IPv6
-----------------------------------
N1 5f00:0000:c001:0200::/56
N2 5f00:0000:c001:0300::/56
N3 5f00:0000:c001:0100::/56
N4 5f00:0000:c001:0400::/56

Table 1: IPv6 link prefixes for sample

Router interface Interface ID link-local
-------------------------------------------------------
RT1 to N1 1 fe80:0001::RT
to N3 2 fe80:0002::RT
RT2 to N2 1 fe80:0001::RT
to N3 2 fe80:0002::RT
RT3 to N3 1 fe80:0001::RT
to N4 2 fe80:0002::RT
RT4 to N3 1 fe80:0001::RT

Table 2: OSPF Interface IDs and link-local

Coltun, et al. Standards Track [Page 24]

RFC 2740 OSPF for IPv6 December 1999

3.4.3.1. Router-

The LS type of a router-LSA is set to the value 0x2001. Router-
have area flooding scope. A router may originate one or more router
LSAs for a given area. Each router-LSA contains an integral number
interface descriptions; taken together, the collection of router-
originated by the router for an area describes the collected
of all the router's interfaces to the area. When multiple router-
are used, they are distinguished by their Link State ID fields

The Options field in the router-LSA should be coded as follows.
V6-bit should be set. The E-bit should be clear if and only if
attached area is an OSPF stub area. The MC-bit should be set if
only if the router is running MOSPF (see [Ref8]). The N-bit should
set if and only if the attached area is an OSPF NSSA area. The R-
should be set. The DC-bit should be set if and only if the router
correctly process the DoNotAge bit when it appears in the LS
field of LSAs (see [Ref11]). All unrecognized bits in the
field should be

To the left of the Options field, the router capability bits V, E
B should be coded according to Section 12.4.1 of [Ref1]. Bit W
be coded according to [Ref8].

Each of the router's interfaces to the area are then described
appending "link descriptions" to the router-LSA. Each
description is 16 bytes long, consisting of 5 fields: (link) Type
Metric, Interface ID, Neighbor Interface ID and Neighbor Router
(see Section A.4.3). Interfaces in state "Down" or "Loopback" are
described (although looped back interfaces can contribute prefixes
Intra-Area-Prefix-LSAs). Nor are interfaces without any
adjacencies described. All other interfaces to the area add zero,
or more link descriptions, the number and content of which depend
the interface type. Within each link description, the Metric field
always set the interface's output cost and the Interface ID field
set to the interface's OSPF Interface ID

Point-to-point
If the neighboring router is fully adjacent, add a Type 1
description (point-to-point). The Neighbor Interface ID field
set to the Interface ID advertised by the neighbor in its
packets, and the Neighbor Router ID field is set to the neighbor'
Router ID

Coltun, et al. Standards Track [Page 25]

RFC 2740 OSPF for IPv6 December 1999

Broadcast and NBMA
If the router is fully adjacent to the link's Designated Router
or if the router itself is Designated Router and is fully
to at least one other router, add a single Type 2 link
(transit network). The Neighbor Interface ID field is set to
Interface ID advertised by the Designated Router in its
packets, and the Neighbor Router ID field is set to the
Router's Router ID

Virtual
If the neighboring router is fully adjacent, add a Type 4
description (virtual). The Neighbor Interface ID field is set
the Interface ID advertised by the neighbor in its Hello packets
and the Neighbor Router ID field is set to the neighbor's
ID. Note that the output cost of a virtual link is
during the routing table calculation (see Section 3.7).

Point-to-MultiPoint
For each fully adjacent neighbor associated with the interface
add a separate Type 1 link description (point-to-point)
Neighbor Interface ID field set to the Interface ID advertised
the neighbor in its Hello packets, and Neighbor Router ID
set to the neighbor's Router ID

As an example, consider the router-LSA that router RT3
originate for Area 1 in Figure 1. Only a single interface must
described, namely that which connects to the transit network N3.
assumes that RT4 has been elected Designated Router of Network N3.

; RT3's router-LSA for Area 1

LS age = 0 ;newly (re)
LS type = 0x2001 ;router-
Link State ID = 0 ;first
Advertising Router = 192.1.1.3 ;RT3's Router
bit E = 0 ;not an AS boundary
bit B = 1 ;area border
Options = (V6-bit|E-bit|R-bit
Type = 2 ;connects to N
Metric = 1 ;cost to N
Interface ID = 1 ;RT3's Interface ID on N
Neighbor Interface ID = 1 ;RT4's Interface ID on N
Neighbor Router ID = 192.1.1.4 ; RT4's Router

If for example another router was added to Network N4, RT3 would
to advertise a second link description for its connection to (the
transit) network N4. This could be accomplished by reoriginating
above router-LSA, this time with two link descriptions. Or,

Coltun, et al. Standards Track [Page 26]

RFC 2740 OSPF for IPv6 December 1999

separate router-LSA could be originated with a separate Link State
(e.g., using a Link State ID of 1) to describe the connection to N4.

Host routes no longer appear in the router-LSA, but are
included in intra-area-prefix-LSAs

3.4.3.2. Network-

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
broadcast or NBMA link having two or more attached routers, by
link's Designated Router. The network-LSA lists all routers
to the link

The procedure for originating network-LSAs in IPv6 is the same as
IPv4 procedure documented in Section 12.4.2 of [Ref1], with
following exceptions

o An IPv6 network-LSA's Link State ID is set to the Interface ID
the Designated Router on the link

o IPv6 network-LSAs do not contain a Network Mask. All
information formerly contained in the IPv4 network-LSA has
been consigned to intra-Area-Prefix-LSAs

o The Options field in the network-LSA is set to the logical OR
the Options fields contained within the link's associated link
LSAs. In this way, the network link exhibits a capability when
least one of the link's routers requests that the capability
asserted

As an example, assuming that Router RT4 has been elected
Router of Network N3 in Figure 1, the following network-LSA
originated

; Network-LSA for Network N

LS age = 0 ;newly (re)
LS type = 0x2002 ;network-
Link State ID = 1 ;RT4's Interface ID on N
Advertising Router = 192.1.1.4 ;RT4's Router
Options = (V6-bit|E-bit|R-bit
Attached Router = 192.1.1.4 ;Router
Attached Router = 192.1.1.1 ;Router
Attached Router = 192.1.1.2 ;Router
Attached Router = 192.1.1.3 ;Router

Coltun, et al. Standards Track [Page 27]

RFC 2740 OSPF for IPv6 December 1999

3.4.3.3. Inter-Area-Prefix-

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
the Autonomous System

The procedure for originating inter-area-prefix-LSAs in IPv6 is
same as the IPv4 procedure documented in Sections 12.4.3 and 12.4.3.1
of [Ref1], with the following exceptions

o The Link State ID of an inter-area-prefix-LSA has lost all of
addressing semantics, and instead simply serves to
multiple inter-area-prefix-LSAs that are originated by the
router

o The prefix is described by the PrefixLength, PrefixOptions
Address Prefix fields embedded within the LSA body. Network
is no longer specified

o The NU-bit in the PrefixOptions field should be clear. The
of the MC-bit depends upon whether, and if so how, MOSPF
operating in the routing domain (see [Ref8]).

o Link-local addresses must never be advertised in inter-area
prefix-LSAs

As an example, the following shows the inter-area-prefix-LSA
Router RT4 originates into the OSPF backbone area, condensing
of Area 1's prefixes into the single prefix 5f00:0000:c001::/48.
The cost is set to 4, which is the maximum cost to all of
prefix' individual components. The prefix is padded out to an
number of 32-bit words, so that it consumes 64-bits of
instead of 48 bits

; Inter-area-prefix-LSA for Area 1
; originated by Router RT4 into the

LS age = 0 ;newly (re)
LS type = 0x2003 ;inter-area-prefix-
Advertising Router = 192.1.1.4 ;RT4's
Metric = 4 ;maximum to
PrefixLength = 48
PrefixOptions = 0
Address Prefix = 5f00:0000:c001 ;padded to 64-

Coltun, et al. Standards Track [Page 28]

RFC 2740 OSPF for IPv6 December 1999

3.4.3.4. Inter-Area-Router-

The LS type of an inter-area-router-LSA is set to the
0x2004. Inter-area-router-LSAs have area flooding scope. In IPv4,
inter-area-router-LSAs were called type 4 summary-LSAs.
inter-area-router-LSA describes a path to a destination
router (an ASBR) that is external to the area, yet internal to
Autonomous System

The procedure for originating inter-area-router-LSAs in IPv6
the same as the IPv4 procedure documented in Section 12.4.3
[Ref1], with the following exceptions

o The Link State ID of an inter-area-router-LSA is no longer
destination router's OSPF Router ID, but instead simply serves
distinguish multiple inter-area-router-LSAs that are originated
the same router. The destination router's Router ID is now
in the body of the LSA

o The Options field in an inter-area-router-LSA should be set
to the Options field contained in the destination router's
router-LSA. The Options field thus describes the
supported by the destination router

As an example, consider the OSPF Autonomous System depicted in
6 of [Ref1]. Router RT4 would originate into Area 1 the
inter-area-router-LSA for destination router RT7.

; inter-area-router-LSA for AS boundary router RT
; originated by Router RT4 into Area 1

LS age = 0 ;newly (re)
LS type = 0x2004 ;inter-area-router-
Advertising Router = 192.1.1.4 ;RT4's
Options = (V6-bit|E-bit|R-bit) ;RT7's
Metric = 14 ;cost to RT
Destination Router ID = Router RT7's

3.4.3.5. AS-external-

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
a path to a prefix external to the Autonomous System

The procedure for originating AS-