RFC 2740

OSPF for IPv6

📅 published December 1999, from ietf

Part 1 of 18 🎀

RFC 2740: OSPF for IPv6 🦋

Okay bestie, this is RFC 2740, and it's called OSPF for IPv6 ✨. It's a Standards Track document from the Network Working Group, dated December 1999. The authors are R. Coltun of Siara Systems, D. Ferguson of Juniper Networks, and J. Moy of Sycamore Networks 👑. The title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅.

Status of This Memo 📜

This document is an Internet standards track protocol for the Internet community, and it's asking everyone to talk about it and suggest improvements 🫶. If you want to know where this protocol stands in the standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🔍. Distribution of this memo is unlimited 🌈.

Copyright Notice ©

Abstract 🌸

Okay so this doc is all about the changes needed to make OSPF work with version 6 of the Internet Protocol (IPv6) 🧚. The core stuff stays the same, like flooding, DR election, area support, SPF calculations, and so on. But some things had to change, either because IPv4 and IPv6 handle protocol semantics differently, or just because IPv6 addresses are way bigger 🙈.

Here's what's different from OSPF for IPv4 💖. Addressing semantics got removed from OSPF packets and the basic LSAs. New LSAs were created to carry IPv6 addresses and prefixes. OSPF now runs per-link instead of per-IP-subnet. Flooding scope for LSAs got generalized. And authentication got pulled out of OSPF itself, because it now leans on IPv6's Authentication Header and Encapsulating Security Payload 🔐.

Even with the bigger addresses, most OSPF for IPv6 packets are still almost as compact as their IPv4 cousins 🍓. Most of the field-size and packet-size limits from OSPF for IPv4 got relaxed, and option handling is more flexible now. Literally so flexible 💅.

And the best part: everything OSPF for IPv4 could do is still supported here. That includes on-demand circuit support, NSSA areas, and the multicast extensions to OSPF (MOSPF) 🔥.

Table of Contents 📚

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

1. Introduction 💖

This doc describes the same modifications to OSPF for IPv6 that the Abstract covered, and the core mechanisms (flooding, DR election, area support, SPF calculations, and so on) are still unchanged 🦋. Some changes were still needed, either because protocol semantics differ between IPv4 and IPv6, or simply to handle IPv6's increased address size 💅.

Here's the roadmap ✨. Section 2 breaks down the differences between OSPF for IPv4 and OSPF for IPv6 in detail. Section 3 gives implementation details for those changes. Appendix A has the OSPF for IPv6 packet and LSA formats. Appendix B lists the OSPF architectural constants. And Appendix C describes the configuration parameters 🗺️.

1.1. Terminology 🧠

This doc tries to use terms from both the OSPF for IPv4 specification ([Ref1]) and the IPv6 protocol specifications ([Ref14]). Honestly, the result is a bit mixed 🙈. Most terms used by both OSPF and IPv6 mean roughly the same thing (interfaces, for example). But there are a few clashes. IPv6 uses "link" kind of like IPv4 OSPF uses "subnet" or "network", so this doc goes with IPv6's "link" terminology 🔗.

So "link" replaces OSPF's "subnet" and "network" in most places here. The exception is OSPF's Network-LSA, which stays the same. And yes, a new Link-LSA was also created, which is possibly unfortunate but here we are 😭.

The names of some OSPF LSAs changed too. Check Section 2.8 for the details 👀.

2. Differences from OSPF for IPv4 🔥

Most of the algorithms from OSPF for IPv4 [Ref1] have been preserved in OSPF for IPv6 🌸. Some changes were still necessary, either because protocol semantics differ between IPv4 and IPv6, or simply to handle IPv6's increased address size.

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

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

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

Because of this, OSPF for IPv6 runs per-link instead of the IPv4 behavior of per-IP-subnet ✨. The terms "network" and "subnet" from the IPv4 OSPF specification ([Ref1]) should generally be replaced by "link". Likewise, an OSPF interface now connects to a link instead of an IP subnet, and so on 💖.

This change affects how OSPF protocol packets are received, and it also affects the contents of Hello Packets and Network-LSAs 🎀.

2.2. Removal of addressing semantics ✨

In OSPF for IPv6, addressing semantics got yeeted from the OSPF protocol packets and the main LSA types, leaving a network-protocol-independent core 💅 Here's what that looks like:

IPv6 Addresses are not present in OSPF packets, except in LSA payloads carried by the Link State Update Packets. See Section 2.7 for details.
Router-LSAs and Network-LSAs no longer contain network addresses. They just express topology information. See Section 2.8 for details.
OSPF Router IDs, Area IDs and LSA Link State IDs stay at the IPv4 size of 32-bits. They can no longer be assigned as (IPv6) addresses 🙈
Neighboring routers are now always identified by Router ID. Previously they were identified by IP address on broadcast and NBMA "networks" 🦋

2.3. Addition of Flooding scope 🌸

Flooding scope for LSAs got a glow-up. It's now explicitly coded in the LSA's LS type field, and there are three separate flooding scopes:

Link-local scope. The LSA is flooded only on the local link, and no further. Used for the new Link-LSA (see Section A.4.8) 🧚
Area scope. The LSA is flooded throughout a single OSPF area only. Used for Router-LSAs, Network-LSAs, Inter-Area-Prefix-LSAs, Inter-Area-Router-LSAs and Intra-Area-Prefix-LSAs 🍓
AS scope. The LSA is flooded throughout the routing domain. Used for AS-external-LSAs 👑

2.4. Explicit support for multiple instances per link 💜

OSPF now supports running multiple OSPF protocol instances on a single link, and this is so iconic 🫶 For example, this may be needed on a NAP segment shared between several providers. The providers might be running separate OSPF routing domains that want to stay separate, even though they share one or more physical network segments (i.e., links). In OSPF for IPv4, this was handled in a haphazard fashion using the authentication fields in the OSPF for IPv4 header 💀

Another reason to run multiple OSPF instances is if you want, for one reason or another, a single link to belong to two or more OSPF areas. Main character energy 👑

Multiple protocol instances on a link are supported through an "Instance ID" that lives in the OSPF packet header and the OSPF interface structures. The Instance ID solely affects the reception of OSPF packets ✨

2.5. Use of link-local addresses 🎀

IPv6 link-local addresses are for use on a single link, for purposes like neighbor discovery and auto-configuration. IPv6 routers do not forward IPv6 datagrams that have link-local source addresses [Ref15]. Link-local unicast addresses are assigned from the IPv6 address range FF80/10 🦋

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

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

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

2.6. Authentication changes 🔐

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

When running over IPv6, OSPF relies on the IP Authentication Header (see [Ref19]) and the IP Encapsulating Security Payload (see [Ref20]) to ensure integrity and authentication/confidentiality of routing exchanges. Outsourcing the security bestie role, and it's giving trust 🛡️

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

2.7. Packet format changes 🦋

OSPF for IPv6 runs directly over IPv6. Aside from that, all addressing semantics have been removed from the OSPF packet headers, which makes it essentially "network-protocol-independent" 💖 All addressing information now lives in the various LSA types only.

Here's the detailed tea on the OSPF packet format changes:

The OSPF version number has been increased from 2 to 3 🔢
The Options field in Hello Packets and Database Description Packets has been expanded to 24-bits.
The Authentication and AuType fields have been removed from the OSPF packet header (see Section 2.6) 🙈
The Hello packet now contains no address information at all. It includes an Interface ID, which the originating router assigns to uniquely identify (among its own interfaces) its interface to the link. This Interface ID becomes the Network-LSA's Link State ID, should the router become Designated-Router on the link 🧚
Two option bits, the "R-bit" and the "V6-bit", have been added to the Options field for processing Router-LSAs during the SPF calculation (see Section A.2). If the "R-bit" is clear, an OSPF speaker can participate in OSPF topology distribution without being used to forward transit traffic. This can be used in multi-homed hosts that want to take part 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 🌈
The OSPF packet header now includes an "Instance ID", which allows multiple OSPF protocol instances to be run on a single link (see Section 2.4) 💜

2.8. LSA format changes 💅

All addressing semantics have been removed from the LSA header, and from Router-LSAs and Network-LSAs. These two LSAs now describe the routing domain's topology in a network-protocol-independent manner. New LSAs have been added to distribute IPv6 address information and the data needed for next hop resolution. Some of IPv4's LSAs got renamed so they match each other better ✨

Here's the detailed tea on the LSA format changes:

The Options field has been removed from the LSA header, expanded to 24 bits, and moved into the body of Router-LSAs, Network-LSAs, Inter-Area-Router-LSAs and Link-LSAs. See Section A.2 for details 🎀
The LSA Type field has been expanded (into the former Options space) to 16 bits, with the upper three bits encoding flooding scope and the handling of unknown LSA types (see Section 2.9) 🔥
Addresses in LSAs are now expressed as [prefix, prefix length] instead of [address, mask] (see Section A.4.1). The default route is expressed as a prefix with length 0 🌸
The Router and Network LSAs now have no address information, and are network-protocol-independent 🦋
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 🧩
A new LSA called the Link-LSA has been introduced. Link-LSAs have local-link flooding scope, so they are never flooded beyond the link they are associated with. Link-LSAs have three purposes: 1) they provide the router's link-local address to all other routers attached to the link, 2) they inform other routers attached to the link of a list of IPv6 prefixes to associate with the link, and 3) they allow the router to assert a collection of Options bits to associate with the Network-LSA that will be originated for the link. See Section A.4.8 for details 🧚

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

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 🔗
Type-3 summary-LSAs have been renamed "Inter-Area-Prefix-LSAs". Type-4 summary LSAs have been renamed "Inter-Area-Router-LSAs" 🏷️
The Link State ID in Inter-Area-Prefix-LSAs, Inter-Area-Router-LSAs and AS-external-LSAs has lost its addressing semantics. It 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 📦
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 📏
A new LSA called the Intra-Area-Prefix-LSA has been introduced. This LSA carries all IPv6 prefix information that in IPv4 is included in Router-LSAs and Network-LSAs. See Section A.4.9 for details 🌟
Including a forwarding address in AS-external-LSAs is now optional, as is including an external route tag (see [Ref5]). In addition, AS-external-LSAs can now reference another LSA, to include additional route attributes that are outside the scope of the OSPF protocol itself. For example, this can be used to attach BGP path attributes to external routes, as proposed in [Ref10] 🫶

2.9. Handling unknown LSA types 🤔

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

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

2.10. Stub area support 🌸

Okay so, in OSPF for IPv4, stub areas were built to keep the link-state database and routing table small for the routers inside them. 🧚 That's what let routers with minimal resources join even very large OSPF routing domains. Iconic, honestly.

In OSPF for IPv6, stub areas are still a thing ✨ Of the mandatory LSA types, stub areas carry only router-LSAs, network-LSAs, Inter-Area-Prefix-LSAs, Link-LSAs, and Intra-Area-Prefix-LSAs. This is the IPv6 version of the LSA types that IPv4 stub areas carry: router-LSAs, network-LSAs and type 3 summary-LSAs.

BUT here's the tea 🫖 Unlike IPv4, IPv6 lets LSAs with unrecognized LS types be labeled "Store and flood the LSA, as if type understood" (see the U-bit in Section A.4.2.1). If these LSAs get introduced without any control, a stub area's link-state database could grow bigger than its component routers' capacities. Not it. 💀

So to guard against that, there's a rule for stub areas: an LSA whose LS type is unrecognized may only be flooded into/throughout a stub area if both a) the LSA has area or link-local flooding scope and b) the LSA has U-bit set to 0. See Section 3.5 for details. Protect the stub area, periodt 🛡️💜

2.11. Identifying neighbors by Router ID 🦋

In OSPF for IPv6, neighboring routers on a given link are always identified by their OSPF Router ID. This is different from IPv4, where neighbors on point-to-point networks and virtual links are identified by their Router IDs, and neighbors on broadcast, NBMA and Point-to-MultiPoint links are identified by their IPv4 interface addresses. Main character energy for the Router ID 👑

This change affects how OSPF packets are received (see Section 8.2 of [Ref1]), how neighbors are looked up (Section 10 of [Ref1]) and how Hello Packets are received (Section 10.5 of [Ref1]).

Also, the Router ID of 0.0.0.0 is reserved, and should not be used. 🙈

3. Implementation details 🎀

Okay, so going from IPv4 to IPv6, the basic OSPF mechanisms stay exactly the same as the ones in [Ref1]. They're quickly outlined in Section 4 of [Ref1]. Both IPv6 and IPv4 have a link-state database made of LSAs, and it's synchronized between adjacent routers. The initial sync happens through the Database Exchange process, which means Database Description, Link State Request and Link State Update packets. After that, the database stays in sync through flooding, using Link State Update and Link State Acknowledgment packets. Both versions use OSPF Hello Packets to discover and maintain neighbor relationships, and to elect Designated Routers and Backup Designated Routers on broadcast and NBMA links. The decision about which neighbor relationships become adjacencies, plus the basic ideas behind inter-area routing, importing external information in AS-external-LSAs, and the various routing calculations, are also the same. Lowkey so satisfying 🫶

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

Both IPv4 and IPv6 use OSPF packet types described in Section 4.3 of [Ref1], namely: Hello, Database Description, Link State Request, Link State Update and Link State Acknowledgment packets. In some cases (e.g., Hello packets) their format has changed somewhat, but the functions of the various packet types stay the same. 📦
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. 🧚
The discovery and maintenance of neighbor relationships, and the selection and establishment of adjacencies, remain the same. This includes election of the Designated Router and Backup Designated Router on broadcast and NBMA links. These mechanisms are described in Sections 7, 7.1, 7.2, 7.3, 7.4 and 7.5 of [Ref1]. 🗳️
The link types (or equivalently, interface types) supported by OSPF remain unchanged, namely: point-to-point, broadcast, NBMA, Point-to-MultiPoint and virtual links. 🔗
The interface state machine, including the list of OSPF interface states and events, and the Designated Router and Backup Designated Router election algorithm, remain unchanged. These are described in Sections 9.1, 9.2, 9.3 and 9.4 of [Ref1]. 💅
The neighbor state machine, including the list of OSPF neighbor states and events, remains unchanged. These are described in Sections 10.1, 10.2, 10.3 and 10.4 of [Ref1]. 🌈
Aging of the link-state database, as well as flushing LSAs from the routing domain through the premature aging process, remains unchanged from the description in Sections 14 and 14.1 of [Ref1]. ⏳

BUT some OSPF protocol mechanisms have changed, as outlined in Section 2 above. These changes are explained in detail in the following subsections, with references to the right sections of [Ref1]. Lots to read, bestie 🍓

The following subsections give you a recipe for turning an IPv4 OSPF implementation into an IPv6 OSPF implementation. 🧁

3.1. Protocol data structures 🗂️

The major OSPF data structures are the same for both IPv4 and IPv6: areas, interfaces, neighbors, the link-state database and the routing table. The top-level data structures for IPv6 are still the ones listed in Section 5 of [Ref1], with these changes:

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

3.1.1. The Area Data structure 🏡

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

3.1.2. The Interface Data structure 🔌

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

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

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

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

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

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

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

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

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

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

3.1.3. The Neighbor Data Structure 🤝

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

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

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

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

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

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

3.2. Protocol Packet Processing ✨

Okay so OSPF for IPv6 runs straight on top of IPv6's network layer 🌸. That means it gets wrapped in one or more IPv6 headers, and the Next Header field of the immediately encapsulating IPv6 header is set to 89. Main character protocol energy 💅

Just like IPv4, OSPF routing protocol packets only travel along adjacencies 🦋. The one exception is Hello packets, which are how the adjacencies get discovered in the first place. The packet types and functions are the same in IPv4 and IPv6, and they're encoded by the Type field of the standard OSPF packet header.

3.2.1. Sending protocol packets

When an IPv6 router sends an OSPF routing protocol packet, it fills in the fields of the standard OSPF for IPv6 packet header (see Section A.3.1) like this 🎀

Version #: Set to 3, the version number of the protocol as documented in this specification.
Type: The type of OSPF packet, such as Link state Update or Hello Packet.
Packet length: The length of the entire OSPF packet in bytes, including the standard OSPF packet header.
Router ID: The identity of the router itself (who is originating the packet).
Area ID: The OSPF area that the packet is being sent into.
Instance ID: The OSPF Instance ID associated with the interface that the packet is being sent out of.
Checksum: The standard IPv6 16-bit one's complement checksum, covering the entire OSPF packet and prepended IPv6 pseudo-header (see Section A.3.1).

Picking the IPv6 source and destination addresses for OSPF routing protocol packets works exactly the same way as the IPv4 logic in Section 8.1 of [Ref1] 🌈. The IPv6 destination address comes from AllSPFRouters, AllDRouters, or the Neighbor IP address at the other end of the adjacency. In IPv6, that last one is an IPv6 link-local address for every link except virtual links.

Sending Link State Request Packets and Link State Acknowledgment Packets stays unchanged from the IPv4 procedures in Sections 10.9 and 13.5 of [Ref1], respectively. Hello Packets are covered in Section 3.2.1.1, and Database Description Packets in Section 3.2.1.2. Link State Update Packets are covered in Section 3.5.2 ✨

3.2.1.1. Sending Hello packets

IPv6 changes how OSPF Hello packets get sent in a few ways (compare to Section 9.5 of [Ref1]) 🧚

Before the Hello Packet goes out an interface, the interface's Interface ID MUST be copied into the Hello Packet.
The Hello Packet doesn't carry an IP network mask anymore, because OSPF for IPv6 runs per-link instead of per-subnet 🍓
Designated Routers and Backup Designated Routers are now shown in Hellos by their Router IDs, not by their IP interface addresses. Advertising the Designated Router (or Backup Designated Router) as 0.0.0.0 means it hasn't been chosen yet.
The Options field in Hello packets got rearranged and bigger, so there are more option bits now 🔥. The ones that MUST be set correctly in Hello packets are:
- The E-bit is set if and only if the interface attaches to a non-stub area.
- The N-bit is set if and only if the interface attaches to an NSSA area (see [Ref9]).
- The DC-bit is set if and only if the router wishes to suppress the sending of future Hellos over the interface (see [Ref11]).

Unrecognized bits in the Hello Packet's Options field SHOULD be cleared.

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

3.2.1.2. Sending Database Description Packets

Database Description packets are sent differently from Section 10.8 of [Ref1] in the following ways 🎀

The Options field in Database Description packets got rearranged and bigger too, so there are more option bits now ✨. The ones that MUST be set correctly in Database Description packets are:
- The MC-bit is set if and only if the router is forwarding multicast datagrams according to the MOSPF specification in [Ref7].
- The DC-bit is set if and only if the router wishes to suppress the sending of Hellos over the interface (see [Ref11]).

Unrecognized bits in the Database Description Packet's Options field SHOULD be cleared.

3.2.2. Receiving protocol packets

Whenever an OSPF protocol packet hits the router, it gets marked with the interface it came in on 👀. For routers with virtual links configured, it's not always obvious which interface the packet belongs to. Take the Router RT11 in Figure 6 of [Ref1]: if RT11 gets an OSPF protocol packet on its interface to Network N8, it might want to link the packet with the interface to Area 2, or with the virtual link to Router RT10 (which is part of the backbone). For the rest of this section, we'll assume the packet is first linked with the non-virtual link 🫶

Before the packet can be passed to OSPF for processing, the following tests MUST be performed on the encapsulating IPv6 headers:

The packet's IP destination address MUST be one of the IPv6 unicast addresses on the receiving interface (this includes link-local addresses), or one of the IP multicast addresses AllSPFRouters or AllDRouters.
The Next Header field of the immediately encapsulating IPv6 header MUST specify the OSPF protocol (89).
Any encapsulating IP Authentication Headers (see [Ref19]) and the IP Encapsulating Security Payloads (see [Ref20]) MUST be processed and/or verified to make sure the OSPF routing exchanges have integrity and authentication/confidentiality 🔐.
Locally originated packets SHOULD NOT be passed on to OSPF. In other words, the source IPv6 address SHOULD be examined to make sure it isn't a multicast packet the router itself generated 🙈.

After the encapsulating IPv6 headers are processed, the OSPF packet header is processed. The fields in the header MUST match the ones configured for the receiving interface. If they don't, the packet SHOULD be discarded:

The version number field MUST specify protocol version 3.
The standard IPv6 16-bit one's complement checksum, covering the entire OSPF packet and prepended IPv6 pseudo-header, MUST be verified (see Section A.3.1) ✅.
The Area ID found in the OSPF header MUST be verified. If both of the following cases fail, the packet SHOULD be discarded. The Area ID specified in the header MUST either:
1. Match the Area ID of the receiving interface. In this case, unlike for IPv4, the IPv6 source address is not restricted to lie on the same IP subnet as the receiving interface. IPv6 OSPF runs per-link, instead of per-IP-subnet 🌸.
2. Indicate the backbone. In this case, the packet has been sent over a virtual link. The receiving router MUST be an area border router, and the Router ID specified in the packet (the source router) MUST be the other end of a configured virtual link. The receiving interface MUST also attach to the virtual link's configured Transit area. If all of these checks succeed, the packet is accepted and is from now on associated with the virtual link (and the backbone area) 👑.
The Instance ID specified in the OSPF header MUST match the receiving interface's Instance ID.
Packets whose IP destination is AllDRouters SHOULD only be accepted if the state of the receiving interface is DR or Backup (see Section 9.1).

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

If the packet type is Hello, it SHOULD then be processed further by the Hello Protocol. All other packet types are only sent and received on adjacencies. That means the packet MUST have been sent by one of the router's active neighbors. The neighbor is identified by the Router ID in the received packet's OSPF header. Packets that don't match any active neighbor are discarded 💀

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

3.2.2.1. Receiving Hello Packets

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

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 🫶.
The Hello Packet no longer has a Network Mask field.
The neighbor's choice of Designated Router and Backup Designated Router is now encoded as an OSPF Router ID instead of an IP interface address.

3.3. The Routing table Structure ✨

okay bestie, let's talk routing tables 🗺️💖 OSPF for IPv4 uses the one from Section 11 of [Ref1]. For IPv6 there are analogous entries: one kind for IPv6 address prefixes, and one for AS boundary routers. The AS boundary router entries only exist to hold intermediate results during the routing table build process (see Section 3.8). they're temporary, like a sticky note 📝

Also, for the intermediate results of the shortest-path calculation for each area, every area gets its own separate routing table, holding these entries:

An entry for each router in the area. Routers are identified by their OSPF router ID 🆔 These entries hold the set of shortest paths through a given area to a given router. That lets you calculate paths to the IPv6 prefixes that router advertises in Intra-area-prefix-LSAs. If the router is also an area-border router, these entries are used to calculate paths for inter-area address prefixes too. And if the router is the other endpoint of a virtual link, the entry describes the cost and viability of that virtual link 🦋
An entry for each transit link in the area. Transit links have associated network-LSAs, and both the transit link and its 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 entries let you later calculate paths to the 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]) are still valid for IPv6 ✨ That means: 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. no notes, it's giving consistency 💅

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

3.3.1. Routing table lookup

Routing table lookup (aka figuring out the best matching routing table entry during IP forwarding) works the same for IPv6 as it does for IPv4 🎀 no new drama here 🙈

3.4. Link State Advertisements

okay so for IPv6, the OSPF LSA header has changed a little 🧚 the LS type field got bigger, and the Options field moved down into the body of certain LSAs. Some LSA formats changed too (router-LSAs, network-LSAs and AS-external-LSAs), and some LSAs got renamed: type 3 and 4 summary-LSAs are now inter-area-prefix-LSAs and inter-area-router-LSAs, respectively. Plus there are new LSAs, Link-LSAs and Intra-Area-Prefix-LSAs 💜 Type of Service (TOS) got removed from the OSPFv2 specification [Ref1], and OSPF for IPv6 doesn't encode it in its LSAs at all. bye TOS 👋

We'll go through all of this in detail in the subsections below 🫶

3.4.1. The LSA Header

In both IPv4 and IPv6, every OSPF LSA starts with a standard 20 byte LSA header. But the contents of that 20 byte header changed for IPv6 🌈 The LS age, Advertising Router, LS Sequence Number, LS checksum and length fields are all unchanged, and they're documented in Sections 12.1.1, 12.1.5, 12.1.6, 12.1.7 and A.4.1 of [Ref1], respectively. These fields changed for IPv6:

Options: The Options field is gone from the standard 20 byte LSA header and now lives in the body of router-LSAs, network-LSAs, inter-area-router-LSAs and link-LSAs. It grew from 8 to 24 bits, and some of the bit definitions changed (see Section A.2). On top of that, a separate PrefixOptions field, 8 bits long, is attached to each prefix advertised in the body of an LSA ✨
LS type: This field grew from 8 to 16 bits. The top two bits encode the flooding scope, and the next bit encodes how unknown LS types are handled 💖 See Section A.4.2.1 for the current coding of the LS type field.
Link State ID: This one stays at 32 bits, but apart from network-LSAs and link-LSAs, it's shed all addressing meaning 🦋 For example, an IPv6 router originating multiple AS-external-LSAs could give the first one a Link State ID of 0.0.0.1, the second 0.0.0.2, and so on. Unlike IPv4, where the network number got encoded in the AS-external-LSA's Link State ID, in IPv6 the Link State ID is just a way to tell apart multiple LSAs from the same router 🧠

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

3.4.2. The link-state database

In IPv6, just like IPv4, individual LSAs are identified by their LS type, Link State ID and Advertising Router fields 🔑 If you have two instances of an LSA, the most recent one is decided by comparing their LS Sequence Numbers, with LS checksum and LS age as tiebreakers (see Section 13.1 of [Ref1]).

Here's where IPv6 gets a little different 👀 The link-state database is split across three separate data structures:

LSAs with AS flooding scope live in the top-level OSPF data structure (see Section 3.1), as long as either their LS type is known or their U-bit is 1 (flood even when unrecognized). This includes the AS-external-LSAs.
LSAs with area flooding scope live in the appropriate area structure (see Section 3.1.1), as long as either their LS type is known or their U-bit is 1 (flood even when unrecognized). This includes router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, and intra-area-prefix-LSAs.
LSAs with an unknown LS type and U-bit set to 0, and/or link-local flooding scope, live in the appropriate interface structure (see Section 3.1.2). This includes link-LSAs.

To look up or install an LSA in the database, you first check the LS type and the LSA's context (i.e., which area or link the LSA belongs to) 🕵️‍♀️ That gets you to the right list of LSAs, all with the same LS type. Then you search that list by the LSA's Link State ID and Advertising Router.

3.4.3. Originating LSAs

Reoriginating an LSA in IPv6 works just like IPv4 🔁 The LSA's LS sequence number gets incremented, its LS age is set to 0, its LS checksum is calculated, and the LSA is added to the link state database and flooded out the appropriate interfaces.

IPv4 has its list of events that cause LSAs to be reoriginated (given in Section 12.4 of [Ref1]). For IPv6, these events and/or actions are added on top:

The state of one of the router's interfaces changes. The router may need to (re)originate or flush its Link-LSA and one or more router-LSAs and/or intra-area-prefix-LSAs.
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.
A neighbor transitions to or 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.
The Interface ID of a neighbor changes. This may cause a new instance of a router-LSA to be originated for the associated area, and the reorigination of one or more intra-area-prefix-LSAs.
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's the only router attached to the link, to reoriginate an intra-area-prefix-LSA.
A new link-LSA is received, causing the link's collection of prefixes to change. If the router is the Designated Router for the link, it originates a new intra-area-prefix-LSA.

The detailed construction of the seven required IPv6 LSA types is covered by the following subsections 📚 To show example LSAs, the network map in Figure 15 of [Ref1] got reworked to use IPv6 addressing, which gives you Figure 1 🗺️ The OSPF cost of each interface is displayed in Figure 1. The IPv6 prefix assignments to network links are in Table 1. A single area address range has been configured for Area 1, so outside of Area 1, all of its prefixes are covered by one route to 5f00:0000:c001::/48 🫶 The OSPF interface IDs and link-local addresses for the router interfaces in Figure 1 are in Table 2.

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

Figure 1: Area 1 with IP addresses shown

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

Table 1: IPv6 link prefixes for sample network

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

Table 2: OSPF Interface IDs and link-local addresses

3.4.3.1. Router-LSAs ✨

okay so router-LSAs are giving main character energy 💅 The LS type is 0x2001, and they have area flooding scope 🌸 A router can make one or more router-LSAs for a given area. Each one holds a whole number of interface descriptions, and all of them together describe the state of every one of the router's interfaces to that area 🦋 When there's more than one, they get told apart by their Link State ID fields.

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

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

Next, each of the router's interfaces to the area gets described by tacking "link descriptions" onto the router-LSA 💖 Each link description is 16 bytes long and has 5 fields: (link) Type, Metric, Interface ID, Neighbor Interface ID and Neighbor Router ID (see Section A.4.3) ✨ Interfaces in state "Down" or "Loopback" are not described, although looped back interfaces can still contribute prefixes to Intra-Area-Prefix-LSAs 🙈 Interfaces without any full adjacencies are skipped too. Every other interface to the area adds zero, one or more link descriptions, and how many and what they say depends on the interface type. Inside each link description, the Metric field is always set to the interface's output cost, and the Interface ID field is set to the interface's OSPF Interface ID 🍓

Point-to-point interfaces 🫶

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

Broadcast and NBMA interfaces 🌈

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

Virtual links 🦋

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

Point-to-MultiPoint interfaces 💜

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

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

  ; RT3's router-LSA for Area 1

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

Now say another router gets added to Network N4. RT3 would then have to advertise a second link description for its connection to (the now transit) network N4 🧚 It could do that by reoriginating the router-LSA above, this time with two link descriptions. Or, a separate router-LSA could be originated with a separate Link State ID (e.g., using a Link State ID of 1) to describe the connection to N4 💅

Host routes don't show up in the router-LSA anymore 🙈 They're included in intra-area-prefix-LSAs instead.

3.4.3.2. Network-LSAs 🌸

The LS type of a network-LSA is set to the value 0x2002. Network-LSAs have area flooding scope 🦋 A network-LSA is originated for every broadcast or NBMA link that has two or more attached routers, by the link's Designated Router 💖 The network-LSA lists all routers attached to the link.

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

An IPv6 network-LSA's Link State ID is set to the Interface ID of the Designated Router on the link.
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.
The Options field in the network-LSA is set to the logical OR of the Options fields contained within the link's associated link-LSAs. In this way, the network link exhibits a capability when at least one of the link's routers requests that the capability be asserted 🫶

As an example, assume that Router RT4 has been elected Designated Router of Network N3 in Figure 1. Then the following network-LSA is originated ✨

  ; Network-LSA for Network N3

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

3.4.3.3. Inter-Area-Prefix-LSAs 👑

The LS type of an inter-area-prefix-LSA is set to the value 0x2003. Inter-area-prefix-LSAs have area flooding scope 🌈 In IPv4, these were called type 3 summary-LSAs. Each inter-area-prefix-LSA describes a prefix that is external to the area, yet internal to the Autonomous System 🧚

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

The Link State ID of an inter-area-prefix-LSA has lost all of its addressing semantics. Instead, it simply serves to distinguish multiple inter-area-prefix-LSAs that are originated by the same router 💜
The prefix is described by the PrefixLength, PrefixOptions and Address Prefix fields embedded within the LSA body. Network Mask is no longer specified.
The NU-bit in the PrefixOptions field should be clear. The coding of the MC-bit depends upon whether, and if so how, MOSPF is operating in the routing domain (see [Ref8]) 🎀
Link-local addresses must never be advertised in inter-area-prefix-LSAs 🚫

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

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

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

3.4.3.4. Inter-Area-Router-LSAs 🧚

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

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

The Link State ID of an inter-area-router-LSA is no longer the destination router's OSPF Router ID. Instead, it 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 🙈
The Options field in an inter-area-router-LSA should be set equal to the Options field contained in the destination router's own router-LSA. The Options field thus describes the capabilities supported by the destination router ✨

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

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

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

3.4.3.5. AS-external-LSAs ✨

okay so AS-external-LSAs are the ones that point at prefixes living outside your Autonomous System 🌍. Their LS type is 0x4005 💅 and they have AS flooding scope, so they get passed around the whole AS 🦋. Each one basically says "hey, there's a path to this external prefix over here" 🫶.

Originating these in IPv6 works the same way as the IPv4 version in Section 12.4.4 of [Ref1] 💖, with a few glow-ups:

The Link State ID has lost all of its addressing vibes 😭. Now it just tells apart multiple AS-external-LSAs that the same router originates 🎀.
The prefix is described by the PrefixLength, PrefixOptions and Address Prefix fields inside the LSA body. Network Mask isn't a thing anymore 💀.
The NU-bit in PrefixOptions should be clear. How the MC-bit gets coded depends on whether, and if so how, MOSPF is running in the routing domain (see [Ref8]) 🔥.
Link-local addresses can never be advertised in AS-external-LSAs 🙅.
The forwarding address is in the AS-external-LSA if and only if bit F is set 🧭.
The external route tag is in the AS-external-LSA if and only if bit T is set 🏷️.
An AS-external-LSA can now reference another LSA 👑. That's done with the Referenced LS Type field and the optional Referenced Link State ID field, and the latter is only there if and only if Referenced LS Type is non-zero. This is for future use 🔮. For now, Referenced LS Type should be set to 0, and received non-zero values for this field should be ignored 🙈.

Let's do an example! 🎀 Picture the OSPF Autonomous System in Figure 6 of [Ref1]. Say RT7 learned its route to N12 through BGP, and it wants to advertise a Type 2 metric into the AS 📣. Also say the IPv6 prefix for N12 is 5f00:0000:0a00::/40. RT7 would then originate this AS-external-LSA for the external network N12. Heads up: N12's prefix takes up 64 bits in the AS-external-LSA so everything stays 32-bit aligned 🦋.

; 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 = 5f00:0000:0a00 ;padded to 64-bits
External Route Tag = as per BGP/OSPF interaction

3.4.3.6. Link-LSAs 🔗

The LS type of a Link-LSA is 0x0008 🍓. Link-LSAs have link-local flooding scope, which means they stay on one link 🧚. A router makes a separate Link-LSA for each attached link that has 2 or more routers on it (the originating router counts too) 💜.

Link-LSAs have three jobs ✨:

They share the router's link-local address with every other router attached to the link 🫶.
They tell the other routers on the link which IPv6 prefixes go with that link 🌸.
They let the router assert a set of Options bits that will show up in the Network-LSA originated for the link 👑.

Here's how a Link-LSA for a given Link L gets built 💅:

The Link State ID is set to the router's Interface ID on Link L.
The Router Priority of the router's interface to Link L goes into the Link-LSA.
The Link-LSA's Options field gets the bits the router wants set in Link L's Network-LSA.
The router puts its link-local address on Link L into the Link-LSA. The other routers on Link L use this when they do their next hop calculations (see Section 3.8.1.1) 🦋.
Every IPv6 address prefix configured into the router for Link L gets added to the Link-LSA, with values for the PrefixLength, PrefixOptions and Address Prefix fields 🎀.

Once the router has built a Link-LSA for a link, it installs it into that interface's data structure and floods it onto the link 🌊. Every other router on the link gets the Link-LSA, but it goes no further 🙈.

Quick tea: the Link-LSA stays on its link. Nothing else in the AS sees it 🤫.

Here's an example! 🔥 Look at the Link-LSA that RT3 builds for N3 in Figure 1. Suppose the prefix 5f00:0000:c001:0100::/56 has been configured on RT3 for N3. That gives this Link-LSA, which RT3 floods onto N3 and nowhere else 🌈. Not every router on N3 has to be configured with the prefix, because the ones that aren't configured will learn it when they receive RT3's Link-LSA 🥹.

; RT3's Link-LSA for N3

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

3.4.3.7. Intra-Area-Prefix-LSAs ✨

okay bestie, the intra-area-prefix-LSA is literally the prefix hype squad 🎀. Its LS type is 0x2009 💖, and it has area flooding scope 🦋. It has one of two jobs. It can tie a list of IPv6 address prefixes to a transit network link by referencing a network-LSA, or tie a list of IPv6 address prefixes to a router by referencing a router-LSA 💅. A stub link's prefixes are associated with its attached router 🌸.

A router can originate multiple intra-area-prefix-LSAs for a given area 🧚. They're told apart by their Link State ID fields. Each one holds an integral number of prefix descriptions 💜.

A link's Designated Router originates one or more intra-area-prefix-LSAs to advertise the link's prefixes throughout the area 👑. For a link L, L's Designated Router builds one like this:

okay so first, to show the prefixes belong to Link L, the Referenced LS type, Referenced Link State ID, and Referenced Advertising Router fields get set to the matching fields in Link L's network-LSA (LS type, Link State ID, and Advertising Router, respectively). So Referenced LS Type is 0x2002, Referenced Link State ID is the Designated Router's Interface ID on Link L, and Referenced Advertising Router is the Designated Router's Router ID 🫶.
next, every Link-LSA associated with Link L gets checked (they live in the Designated Router's interface structure for Link L) 🔍. If the Link-LSA's Advertising Router is fully adjacent to the Designated Router, the list of prefixes in that Link-LSA gets copied into the intra-area-prefix-LSA being built. Prefixes with the NU-bit and/or LA-bit set in their Options field should not be copied, and link-local addresses should not be copied either 🙈. Each prefix is described by the PrefixLength, PrefixOptions, and Address Prefix fields. Multiple prefixes with the same PrefixLength and Address Prefix count as duplicates. In that case their Prefix Options fields get merged by logically OR'ing them together, and one single resulting prefix gets copied in 🧩. The Metric field for all prefixes is set to 0.
the "# prefixes" field is set to the number of prefixes the router copied into the LSA. If the LSA is getting too big, the prefix list can be spread across multiple intra-area-prefix-LSAs to keep the size small 📦.

A router builds an intra-area-prefix-LSA to advertise its own prefixes and those of its attached stub links 💜. A Router RTX would build its intra-area-prefix-LSA like this:

RTX sets Referenced LS type to 0x2001, Referenced Link State ID to 0, and Referenced Advertising Router to RTX's own Router ID, so the prefixes get tied to RTX itself 🎀.
RTX looks over its list of interfaces to the area. If an interface is in state Down, its prefixes are not included 🚫. If the interface has been reported in RTX's router-LSA as a Type 2 link description (link to transit network), its prefixes are not included either, since they'll show up in the intra-area-prefix-LSA for the link instead 🦋. If the interface type is Point-to-MultiPoint, or the interface is in state Loopback, or the interface connects to a point-to-point link that hasn't been assigned a prefix, then any site-local and global scope IPv6 addresses on that interface (if there are any) get copied in. The LA-bit gets set in PrefixOptions, PrefixLength is set to 128, and Metric is set to 0 ✨. Otherwise, the site-local and global prefixes configured in RTX for the link get copied in by specifying PrefixLength, PrefixOptions, and Address Prefix. The Metric for each of these is set to the interface's output cost 💅.
RTX adds the IPv6 prefixes for any directly attached hosts that belong to the area (see Section C.7) 🌈.
if RTX has one or more virtual links configured through the area, it includes one of its site-local or global scope IPv6 interface addresses in the LSA (if it isn't in there already). It sets the LA-bit in PrefixOptions, sets PrefixLength to 128, and sets Metric to 0. This info gets used later in the routing calculation so the two ends of the virtual link can find each other's IPv6 addresses 🔥.
the "# prefixes" field is set to the number of prefixes RTX copied into the LSA. If necessary, the list can be spread across multiple intra-area-prefix-LSAs to keep the LSA size small 🍓.

For example, the intra-area-prefix-LSA that RT4 originates for Network N3 (assuming RT4 is N3's Designated Router) and the intra-area-prefix-LSA that Router RT3 originates into Area 1 for its own prefixes are pictured below 📸.

; Intra-area-prefix-LSA
; for network link N3

LS age = 0                  ;newly (re)originated
LS type = 0x2009            ;Intra-area-prefix-LSA
Link State ID = 5           ;or something
Advertising Router = 192.1.1.4 ;RT4's Router ID
# prefixes = 1
Referenced LS type = 0x2002 ;network-LSA reference
Referenced Link State ID = 1
Referenced Advertising Router = 192.1.1.4
PrefixLength = 56           ;N3's prefix
PrefixOptions = 0
Metric = 0
Address Prefix = 5f00:0000:c001:0100 ;pad

; RT3's Intra-area-prefix-LSA
; for its own prefixes

LS age = 0                  ;newly (re)originated
LS type = 0x2009            ;Intra-area-prefix-LSA
Link State ID = 177         ;or something
Advertising Router = 192.1.1.3 ;RT3's Router ID
# prefixes = 1
Referenced LS type = 0x2001 ;router-LSA reference
Referenced Link State ID = 0
Referenced Advertising Router = 192.1.1.3
PrefixLength = 56           ;N4's prefix
PrefixOptions = 0
Metric = 2                  ;N4 interface cost
Address Prefix = 5f00:0000:c001:0400 ;pad

When network conditions change, a router may need to move prefixes from one intra-area-prefix-LSA to another 🔄. For example, if the router is the Designated Router for a link but the link has no other attached routers, the link's prefixes get advertised in an intra-area-prefix-LSA that refers to the Designated Router's router-LSA. When more routers show up on the link, a network-LSA is originated for it, and the link's prefixes move to an intra-area-prefix-LSA that refers to that network-LSA 🎉.

Note that in the intra-area-prefix-LSA, the "Referenced Advertising Router" is always equal to the router that's originating the LSA (the LSA's Advertising Router) 🧐. The reason the Referenced Advertising Router field exists is that, even though it's redundant right now, it might not be in the future. We may someday want to use the same LSA format to advertise address prefixes for other protocol suites. In that case, the Designated Router might not be running the other protocol suite, so another of the link's routers may need to send out the prefix-LSA. Then "Referenced Advertising Router" and "Advertising Router" would be different 💜.

3.5. Flooding 🌊

most of the flooding algorithm stays the same as the IPv4 flooding mechanisms in Section 13 of [Ref1] 🙌. Specifically, figuring out which LSA instance is newer (Section 13.1 of [Ref1]), responding to updates of self-originated LSAs (Section 13.4 of [Ref1]), sending Link State Acknowledgment packets (Section 13.5 of [Ref1]), retransmitting LSAs (Section 13.6 of [Ref1]), and receiving Link State Acknowledgment packets (Section 13.7 of [Ref1]) work exactly the same for IPv6 and IPv4 💖.

BUT, adding flooding scope and handling options for unrecognized LSA types (see Section A.4.2.1) has changed a few things in the OSPF flooding algorithm 😭. Receiving Link State Updates (Section 13 in [Ref1]) and sending Link State Updates (Section 13.3 of [Ref1]) now have to take the LSA's scope and U-bit setting into account. Installing LSAs into the OSPF database (Section 13.2 of [Ref1]) also triggers different events in IPv6, because the LSA types and contents got reorganized 🧠. All the details are below 👇.

3.5.1. Receiving Link State Update packets 📥

the encoding of flooding scope in the LS type, plus the need to process unknown LS types, changes how received Link State Update packets get handled 🔀. As in IPv4, each LSA in a received Link State Update packet gets examined. In IPv4, eight steps run for each LSA, as described in Section 13 of [Ref1]. For IPv6, all the steps are the same, except that Steps 2 and 3 are modified as follows:

(2) examine the LSA's LS type. If the LS type is unknown, the area has been configured as a stub area, and either the LSA's flooding scope is set to "AS flooding scope" or the U-bit of the LS type is set to 1 (flood even when unrecognized), then discard the LSA and get the next one from the Link State Update Packet. This generalizes the IPv4 behavior where AS-external-LSAs are not flooded into or throughout stub areas 🏝️.
(3) else if the flooding scope of the LSA is set to "reserved", discard the LSA and get the next one from the Link State Update Packet 🗑️.

Steps 5b (sending Link State Update packets) and 5d (installing LSAs in the link state database) in Section 13 of [Ref1] are also a bit different for IPv6, as described in Sections 3.5.2 and 3.5.3 below 🫶✨

3.5.2. Sending Link State Update packets

okay bestie, sending Link State Update packets is covered in Section 13.3 of [Ref1] 💖. For IPv4 and IPv6 the steps are literally the same (steps 1 through 5 of Section 13.3 in [Ref1]) 🫶. The only thing that changes is the list of eligible interfaces to flood the LSA out of. For IPv6, that list gets picked based on these factors:

The LSA's flooding scope. 🌸
For LSAs with area or link-local flooding scoping, the particular area or interface that the LSA is associated with. 🦋
Whether the LSA has a recognized LS type. ✨
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 it's set to 1, unrecognized LS types are stored and flooded as if they were recognized. 💅

Choosing the set of eligible interfaces then splits into three cases, so let's go 🎀

Case 1

The LSA's LS type is recognized, so the set of eligible interfaces depends on the flooding scope encoded in the LS type 👑. If the flooding scope is "AS flooding scope", the eligible interfaces are all router interfaces except virtual links. Also, AS-external-LSAs are not flooded out interfaces connecting to stub areas 🙈. If the flooding scope is "area flooding scope", the eligible interfaces are those connecting to the LSA's associated area 🌈. If the flooding scope is "link-local flooding scope", there is a single eligible interface, the one connecting to the LSA's associated link. When the LSA was received in a Link State Update packet, that's also the interface it came in on 🧚

Case 2

The LS type is unrecognized and the U-bit is set to 0, so we treat the LSA as having link-local flooding scope 🫠. In this case there's a single eligible interface, the interface the LSA was received on 💜

Case 3

The LS type is unrecognized and the U-bit is set to 1, so we store and flood the LSA as if the type were understood 🔥. Pick the eligible interfaces based on the encoded flooding scope, same as Case 1. The one twist is that interfaces attached to stub areas are always excluded 🚫

A further decision sometimes has to be made before adding an LSA to a given neighbor's link-state retransmission list (Step 1d in Section 13.3 of [Ref1]) 🍓. If the LS type is recognized by the router but not by the neighbor (you can tell by checking the Options field 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 that neighbor's link-state retransmission list if and only if the neighbor is the Designated Router or Backup Designated Router for the attached link 🫶

The LS types described in detail by this memo are assumed to be understood by all routers, and they are:

router-LSAs (LS type 0x2001)
network-LSAs (0x2002)
Inter-Area-Prefix-LSAs (0x2003)
Inter-Area-Router-LSAs (0x2004)
AS-External-LSAs (0x4005)
Link-LSAs (0x0008)
Intra-Area-Prefix-LSAs (0x2009)

As an example, the group-membership-LSA (0x2006) is understood only by MOSPF routers. Since its U-bit is set to 0, it should only be forwarded to a non-MOSPF neighbor (you check this by looking at the MC-bit in the neighbor's Database Description packets' Options field) when that neighbor is the Designated Router or Backup Designated Router for the attached link 🦋

The previous paragraph fixes a problem in IPv4 OSPF extensions such as MOSPF. Those extensions require the Designated Router to support the extension before the new LSA types can be flooded across broadcast and NBMA networks (see Section 10.2 of [Ref8]) 💀

3.5.3. Installing LSAs in the database

There are three separate places to store LSAs, depending on their flooding scope 🗂️. LSAs with AS flooding scope are stored in the global OSPF data structure (see Section 3.1) as long as their LS type is known or their U-bit is 1. LSAs with area flooding scope are stored in the appropriate area data structure (see Section 3.1.1) under the same condition. LSAs with link-local flooding scope, plus LSAs with an unknown LS type and U-bit set to 0 (treated as link-local), are stored in the appropriate interface structure 🌸

When storing an LSA into the link-state database, a check must be made to see whether the LSA's contents have changed 🔍. Changes in contents are indicated exactly as in Section 13.2 of [Ref1]. When an LSA's contents have changed, the following parts of the routing table must be recalculated, based on the LS type:

Router-LSAs, Network-LSAs, Intra-Area-Prefix-LSAs and Link-LSAs The entire routing table is recalculated, starting with the shortest path calculation for each area (see Section 3.8) 🔄

Inter-Area-Prefix-LSAs and Inter-Area-Router-LSAs The best route to the destination described by the LSA must be recalculated (see Section 16.5 in [Ref1]). If this destination is an AS boundary router, it may also be necessary to re-examine all the AS-external-LSAs 👀

AS-external-LSAs The best route to the destination described by the AS-external-LSA must be recalculated (see Section 16.6 in [Ref1]) 🎯

As in IPv4, any old instance of the LSA must be removed from the database when the new LSA is installed. That old instance must also be removed from all neighbors' link-state retransmission lists 🧹✨

3.6. Definition of self-originated LSAs

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

3.7. Virtual links

OSPF virtual links for IPv4 are described in Section 15 of [Ref1]. Virtual links are the same in IPv6, with a few exceptions 🌉

LSAs with AS flooding scope are never flooded over virtual adjacencies, and LSAs with AS flooding scope aren't summarized over virtual adjacencies during the Database Exchange process either. This is a generalization of the IPv4 treatment of AS-external-LSAs 🙅‍♀️
The IPv6 interface address of a virtual link must be an IPv6 address with site-local or global scope, instead of the link-local addresses used by other interface types. This address is used as the IPv6 source for OSPF protocol packets sent over the virtual link 🌷
Likewise, the virtual neighbor's IPv6 address is an IPv6 address with site-local or global scope. To discover a virtual neighbor's IPv6 address during the routing calculation, the neighbor advertises its virtual link's IPv6 interface address in an Intra-Area-Prefix-LSA originated for the virtual link's transit area (see Sections 3.4.3.7 and 3.8.1) 🔎
Like all other IPv6 OSPF interfaces, virtual links are assigned Interface IDs that are unique within the router. These are advertised in Hellos sent over the virtual link, and in the router's router-LSAs 🆔

3.8. Routing table calculation

The IPv6 OSPF routing calculation follows the same lines as the IPv4 one, using the five steps specified by Section 16 of [Ref1] 🧮. The big high-level differences between the IPv6 and IPv4 calculations are:

Prefix information has been removed from router-LSAs and is now advertised in intra-area-prefix-LSAs. Whenever [Ref1] says stub networks within router-LSAs should be examined, IPv6 examines the prefixes within intra-area-prefix-LSAs instead 💖
Type 3 and 4 summary-LSAs have been renamed inter-area-prefix-LSAs and inter-area-router-LSAs (respectively) 🏷️
Addressing information is no longer encoded in Link State IDs. It must instead be found within the body of the LSAs 📦
In IPv6, a router can originate multiple router-LSAs within a single area, distinguished by Link State ID. These router-LSAs must be treated as a single aggregate by the area's shortest path calculation (see Section 3.8.1) 🌟

For each area, routing table entries are created for the area's routers and transit links, so the results of the area's shortest-path tree calculation can be stored (see Section 3.8.1). These entries are then used when processing intra-area-prefix-LSAs, inter-area-prefix-LSAs and inter-area-router-LSAs, as described in Section 3.8.2 🦢

Events generated as a result of routing table changes (Section 16.7 of [Ref1]) and the equal-cost multipath logic (Section 16.8 of [Ref1]) are identical for both IPv4 and IPv6 🎉

3.8.1. Calculating the shortest path tree for an area

okay so the IPv4 shortest path calculation lives in Section 16.1 of [Ref1] 💅 and the graph used for the shortest-path tree is literally identical for IPv4 and IPv6 🦋✨. The 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 get routing table entries within the area (see Section 3.3) 💖.

Section 16.1 of [Ref1] splits the shortest path calculations into two stages 🔥. First the Dijkstra calculation runs, and then the stub links get added onto the tree as leaves. IPv6 keeps that split too 👑.

The Dijkstra calculation for IPv6 is identical to the IPv4 one, with the following exceptions (referencing the steps from the Dijkstra calculation as described in Section 16.1 of [Ref1]):

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. 🦋
In Step 2, when a router Vertex V has just been added to the shortest path tree, there may be multiple LSAs associated with the router. All Router-LSAs with Advertising Router set to V's OSPF Router ID must processed as an aggregate, treating them as fragments of a single large router-LSA. The Options field and the router type bits (bits W, V, E and B) should always be taken from "fragment" with the smallest Link State ID. 🫶
Step 2a is not needed in IPv6, as there are no longer stub network links in router-LSAs. 💀
In Step 2b, if W is a router, there may again be multiple LSAs associated with the router. All Router-LSAs with Advertising Router set to W's OSPF Router ID must processed as an aggregate, treating them as fragments of a single large router-LSA. 🌈
In Step 4, there are now per-area routing table entries for each of an area's routers, instead of just the area border routers. These entries subsume all the functionality of IPv4's area border router routing table entries, including the maintenance of virtual links. When the router added to the area routing table in this step is the other end of a virtual link, the virtual neighbor's IP address is set as follows: The collection of intra-area-prefix-LSAs originated by the virtual neighbor is examined, with the virtual neighbor's IP address being set to the first prefix encountered having the "LA-bit" set. ⭐
Routing table entries for transit networks, which are no longer associated with IP networks, are also modified in Step 4. 🎀

The next stage of the shortest path calculation proceeds similarly to the two steps of the second stage of Section 16.1 in [Ref1]. However, instead of examining the stub links within router-LSAs, the list of the area's intra-area-prefix-LSAs is examined. A prefix advertisement whose "NU-bit" is set should not be included in the routing calculation. The cost of any advertised prefix is the sum of the prefix' advertised metric plus the cost to the transit vertex (either router or transit network) identified by intra-area-prefix-LSA's Referenced LS type, Referenced Link State ID and Referenced Advertising Router fields. This latter cost is stored in the transit vertex' routing table entry for the area. 🧁

3.8.1.1. The next hop calculation

ngl this part is so satisfying 🍓. In IPv6, the calculation of the next hop's IPv6 address (which will be a link-local address) goes along the same lines as the IPv4 next hop calculation (see Section 16.1.1 of [Ref1]) 💜. The only difference is in calculating the next hop IPv6 address for a router (call it Router X) which shares a link with the calculating router. In this case the calculating router assigns the next hop IPv6 address to be the link-local interface address contained in Router X's Link-LSA (see Section A.4.8) for the link. This procedure is necessary since on some links, such as NBMA links, the two routers need not be neighbors, and therefore might not be exchanging OSPF Hellos 🙈.

3.8.2. Calculating the inter-area routes

Calculating inter-area routes for IPv6 goes along the same lines as the IPv4 calculation in Section 16.2 of [Ref1], with the following modifications 🌸:

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. 🦋
The Link State ID of the above LSA types no longer encodes the network or router described by the LSA. Instead, an address prefix is contained in the body of an inter-area-prefix-LSA, and a described router's OSPF Router ID is carried in the body of an inter-area-router-LSA. ✨
Prefixes having the "NU-bit" set in their Prefix Options field should be ignored by the inter-area route calculation. 🙈

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

3.8.3. Examining transit areas' summary-LSAs

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

3.8.4. Calculating AS external routes

The IPv6 AS external route calculation goes along the same lines as the IPv4 calculation in Section 16.4 of [Ref1], with the following exceptions 👑:

The Link State ID of the AS-external-LSA types no longer encodes the network described by the LSA. Instead, an address prefix is contained in the body of an AS-external-LSA. 🧚
The default route is described by AS-external-LSAs which advertise zero length prefixes. 💖
Instead of comparing the AS-external-LSA's Forwarding address field to 0.0.0.0 to see whether a forwarding address has been used, bit F of the external-LSA is examined. A forwarding address is in use if and only if bit F is set. 🌈
Prefixes having the "NU-bit" set in their Prefix Options field should be ignored by the inter-area route calculation. 🎀

When a single AS-external-LSA has changed, the incremental calculations outlined in Section 16.6 of [Ref1] can be performed instead of recalculating the entire routing table ⭐.

3.9. Multiple interfaces to a single link

okay this one is giving multi-device main character energy 🦋✨. In OSPF for IPv6, a router may have multiple interfaces to a single link. All interfaces are involved in the reception and transmission of data traffic, however only a single interface sends and receives OSPF control traffic. In more detail 💅:

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

References

[Ref1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[Ref2] McKenzie, A., "ISO Transport Protocol specification ISO DP 8073", RFC 905, April 1984.
[Ref3] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, November 1997.
[Ref4] Fuller, V., Li, T, Yu, J. and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[Ref5] Varadhan, K., Hares, S. and Y. Rekhter, "BGP4/IDRP for IP---OSPF Interaction", RFC 1745, December 1994
[Ref6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[Ref7] deSouza, O. and M. Rodrigues, "Guidelines for Running OSPF Over Frame Relay Networks", RFC 1586, March 1994.
[Ref8] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[Ref9] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, March 1994.
[Ref10] Ferguson, D., "The OSPF External Attributes LSA", unpublished.
[Ref11] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[Ref12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[Ref13] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[Ref14] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[Ref15] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[Ref16] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" RFC 2463, December 1998.
[Ref17] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[Ref18] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[Ref19] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[Ref20] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.

A. OSPF data formats ✨

this appendix is where the actual packet and LSA formats live 🧚💖. It describes the format of OSPF protocol packets and OSPF LSAs. The OSPF protocol runs directly over the IPv6 network layer 🌐. Before any data formats are described, the details of the OSPF encapsulation are explained 🎀.

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

OSPF packet formats are detailed in Section A.3 🦋.

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

A.1 Encapsulation of OSPF packets ✨

okay so OSPF runs directly on top of IPv6's network layer 💅 which means its packets only get wrapped up by IPv6 and local data-link headers. no extra layers, bestie 🫶

OSPF doesn't have its own way to fragment its protocol packets 😭 so when a packet is bigger than the link MTU, it depends on IPv6 fragmentation. the length of an OSPF packet can go up to 65,535 bytes if it needs to. the packet types that tend to get big (Database Description, Link State Request, Link State Update, and Link State Acknowledgment packets) can usually be split into several separate protocol packets without losing any functionality. this is recommended, and IPv6 fragmentation should be avoided whenever possible 🌸 with that in mind, an attempt should be made to limit the sizes of OSPF packets sent over virtual links to 1280 bytes, unless Path MTU Discovery is being performed [Ref14].

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

Use of IPv6 multicast. Some OSPF messages are multicast when they're sent over broadcast networks 🦋 Two distinct IP multicast addresses are used. Packets sent to these multicast addresses should never be forwarded, because they're meant to travel a single hop only. So the multicast addresses have been chosen with link-local scope, and packets sent to these addresses should have their IPv6 Hop Limit set to 1.
- AllSPFRouters: This multicast address has been assigned the value FF02::5. All routers running OSPF should be prepared to receive packets sent to this address. Hello packets are always sent to this destination. Also, certain OSPF protocol packets are sent to this address during the flooding procedure.
- AllDRouters: This multicast address has been assigned the value FF02::6. Both the Designated Router and Backup Designated Router must be prepared to receive packets destined to this address. Certain OSPF protocol packets are sent to this address during the flooding procedure.
OSPF is IP protocol 89. This number should be inserted in the Next Header field of the encapsulating IPv6 header 🧚

A.2 The Options field ✨

the 24-bit OSPF Options field shows up in OSPF Hello packets, Database Description packets, and certain LSAs (router-LSAs, network-LSAs, inter-area-router-LSAs, and link-LSAs) 💖 It lets OSPF routers turn optional capabilities on (or not), and tell each other what level they're at. that's how routers with different capabilities can hang out in the same OSPF routing domain. iconic 👑

an option mismatch between routers can cause all kinds of behaviour, depending on which option it is ngl 💀 some mismatches stop neighbour relationships from forming (like the E-bit below), and you catch those through Hello packets. some stop certain LSA types from being flooded across adjacencies (like the MC-bit below), and you spot those through Database Description packets. some stop routers from being included in routing calculations because they've got reduced functionality (the MC-bit is an example here too), and you find those by looking at LSAs.

Six bits of the OSPF Options field have been assigned. Routers should reset (i.e. clear) unrecognized bits in the Options field when sending Hello packets or Database Description packets and when originating LSAs. the flip side is that routers who see unrecognized Option bits in received Hello packets, Database Description packets, or LSAs should ignore that capability and process the packet/LSA normally 🌈

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

                        The Options field

V6-bit: If this bit is clear, the router/link should be excluded from IPv6 routing calculations. See Section 3.8 of this memo.
E-bit: This bit describes the way AS-external-LSAs are flooded, as described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [Ref1].
MC-bit: This bit describes whether IP multicast datagrams are forwarded according to the specifications in [Ref7].
N-bit: This bit describes the handling of Type-7 LSAs, as specified in [Ref8].
R-bit: This bit (the Router bit) indicates whether the originator is an active router 🦋 If the router bit is clear, routes which transit the advertising node cannot be computed. Clearing the router bit would be appropriate for a multi-homed host that wants to participate in routing, but does not want to forward non-locally addressed packets.
DC-bit: This bit describes the router's handling of demand circuits, as specified in [Ref10].

A.3 OSPF Packet Formats ✨

there are five distinct OSPF packet types 🎀 All of them begin with a standard 16 byte header. that header gets described first, and then each packet type gets its own succeeding section. in those sections you see how each packet gets divided into fields, and then the field definitions are listed out.

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

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

A.3.1 The OSPF packet header ✨

Every OSPF packet starts with a standard 16 byte header 💖 Together with the encapsulating IPv6 headers, the OSPF header contains all the information needed to figure out whether the packet should be accepted for further processing. that determination is described in Section 3.2.2 of this memo.

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

Version #: The OSPF version number. This specification documents version 3 of the OSPF protocol.
Type: The OSPF packet types are as follows. See Sections A.3.2 through A.3.6 for details.

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

Packet length: The length of the OSPF protocol packet in bytes. This length includes the standard OSPF header.
Router ID: The Router ID of the packet's source.
Area ID: A 32 bit number identifying the area that this packet belongs to 🌸 All OSPF packets are associated with a single area. Most travel a single hop only. Packets travelling over a virtual link are labelled with the backbone Area ID of 0.
Checksum: OSPF uses the standard checksum calculation for IPv6 applications 🔥 That's the 16-bit one's complement of the one's complement sum of the entire contents of the packet, starting with the OSPF packet header, and prepending a "pseudo-header" of IPv6 header fields, as specified in [Ref14, section 8.1]. The "Upper-Layer Packet Length" in the pseudo-header is set to the value of the OSPF packet header's length field. The Next Header value used in the pseudo-header is 89. If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before checksumming. Before computing the checksum, the checksum field in the OSPF packet header is set to 0.
Instance ID: Enables multiple instances of OSPF to be run over a single link 🧚 Each protocol instance would be assigned a separate Instance ID. The Instance ID has local link significance only. Received packets whose Instance ID is not equal to the receiving interface's Instance ID are discarded.
0: These fields are reserved. They must be 0 🌈

A.3.2 The Hello packet ✨

okay so Hello packets are OSPF packet type 1 🫶 Routers send them out regularly on every interface (virtual links included) to set up and keep neighbor relationships going. On links that can do multicast or broadcast, they also get multicast, so routers can find each other automatically. no cap, that's main character discovery energy 🦋

Every router on the same link has to agree on a couple of parameters: HelloInterval and RouterDeadInterval. Those values ride along in the Hello packets, so if they don't match, neighbor relationships can't form 🙅‍♀️ The Hello packet also carries the fields for Designated Router election (Designated Router ID and Backup Designated Router ID), plus a list of the Router IDs of neighbors whose Hellos were recently received, which is how a router checks that communication is bi-directional 💜

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

Here's the field breakdown, bestie 💅

Interface ID: a 32-bit number that uniquely identifies this interface among this router's interfaces. Some implementations can use the MIB-II IfIndex for this ([Ref3]) 🔢
Rtr Pri: this router's Router Priority, used in (Backup) Designated Router election. If it's set to 0, the router is ineligible to become (Backup) Designated Router 🙈
Options: the optional capabilities the router supports, as documented in Section A.2 🎀
HelloInterval: the number of seconds between this router's Hello packets ⏱️
RouterDeadInterval: the number of seconds before a silent router gets declared down 💀
Designated Router ID: the identity of the Designated Router for this network, as the sending router sees it. It's identified by its Router ID, and it's set to 0.0.0.0 if there isn't one 👑
Backup Designated Router ID: the identity of the Backup Designated Router for this network, as the sending router sees it. It's identified by its IP Router ID, and it's set to 0.0.0.0 if there isn't one 🧚
Neighbor ID: the Router IDs of each router whose valid Hello packets have been seen recently on the network. "Recently" means within the last RouterDeadInterval seconds ⭐

A.3.3 The Database Description packet 🌈

Database Description packets are OSPF packet type 2, and they get exchanged when an adjacency is being initialized 🤝 Their job is to describe the contents of the link-state database. One packet might not be enough, so there's a poll-response procedure: one router is the master and the other is the slave. The master sends Database Description packets (polls), and the slave acknowledges each one with its own Database Description packet (responses). The responses are linked to the polls through their DD sequence numbers 🔗

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

The Database Description packet is pretty similar to the Link State Request and Link State Acknowledgment packets. All three are basically a list of items, and each item describes a piece of the link-state database 📋 Sending these is covered in Section 10.8 of [Ref1], and receiving them is covered in Section 10.6 of [Ref1] 📬

Options: the optional capabilities the router supports, as documented in Section A.2 🎀
Interface MTU: the size in bytes of the largest IPv6 datagram that can go out the associated interface without fragmentation. You can find the MTUs of common Internet link types in Table 7-1 of [Ref12]. It should be set to 0 in Database Description packets sent over virtual links 📏
I-bit: the Init bit. When it's set to 1, this packet is the first in the sequence of Database Description packets 🥇
M-bit: the More bit. When it's set to 1, more Database Description packets are coming 🍓
MS-bit: the Master/Slave bit. When it's set to 1, the router is the master during the Database Exchange process. Otherwise, it's the slave 👑
DD sequence number: used to sequence the collection of Database Description packets. The initial value (the one marked by the Init bit) should be unique. After that, the DD sequence number goes up until the whole database description has been sent 🔢

The rest of the packet is a (possibly partial) list of the link-state database's pieces. Each LSA in the database gets described by its LSA header, which is documented in Section A.4.1 🧩 That header has everything needed to uniquely identify both the LSA and its current instance 💖

A.3.4 The Link State Request packet 🔍

Link State Request packets are OSPF packet type 3. After a router swaps Database Description packets with a neighbor, it might notice that parts of its link-state database are out-of-date 😬 That's when it sends a Link State Request packet to ask the neighbor for the pieces that are more up-to-date. Sometimes it takes multiple Link State Request packets to get everything 🫠

A router that sends a Link State Request packet knows exactly which instance of each database piece it wants. Every instance is defined by its LS sequence number, LS checksum, and LS age, but those fields aren't actually in the Link State Request packet itself. The router might even get back instances that are more recent than the one it asked for ✨

Sending these is documented in Section 10.9 of [Ref1], and receiving them is documented in Section 10.7 of [Ref1] 📚

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

Each requested LSA is identified by its LS type, Link State ID, and Advertising Router 🎯 That combo uniquely identifies the LSA, but not which instance of it. Link State Request packets are understood to be asking for the most recent instance, whatever that happens to be 🌸

A.3.5 The Link State Update packet ✨

Okay bestie, Link State Update packets are OSPF packet type 4 and they're the ones doing the flooding of LSAs 🌊. Each one carries a bunch of LSAs one hop further away from where they started, and you can fit several LSAs in a single packet 📦.

Link State Update packets get multicast on physical networks that support multicast or broadcast. To make flooding reliable, flooded LSAs get acknowledged in Link State Acknowledgment packets 🫶. If something needs retransmitting, the retransmitted LSAs always go out in unicast Link State Update packets. For the full reliable flooding tea, check out Section 3.5 💅.

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

# LSAs: the number of LSAs included in this update 🔢

The body of the Link State Update packet is a list of LSAs. Each LSA starts with a common 20 byte header, which you'll find in Section A.4.2 🎀. The detailed formats for the different LSA types live in Section A.4 💜.

A.3.6 The Link State Acknowledgment packet 🦋

Link State Acknowledgment packets are OSPF packet type 5. They're how flooding stays reliable, because flooded LSAs get explicitly acknowledged 🙌. The sending of these packets is documented in Section 13.5 of [Ref1], and the reception is documented in Section 13.7 of [Ref1] 🌸.

Multiple LSAs can get acknowledged in one Link State Acknowledgment packet 📬. Depending on the state of the sending interface and who sent the corresponding Link State Update packet, the acknowledgment goes either to the multicast address AllSPFRouters, to the multicast address AllDRouters, or as a unicast (see Section 13.5 of [Ref1] for the deets) 🧚.

This packet is basically a sibling of the Data Description packet. The body of both is simply a list of LSA headers 👯.

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

Each acknowledged LSA gets described by its LSA header. That header is documented in Section A.4.2, and it has everything needed to uniquely identify both the LSA and its current instance 🔍✨.

A.4 LSA formats 💖

This memo defines seven distinct types of LSAs 💜. Every LSA starts with a standard 20 byte LSA header, which is explained in Section A.4.2, and then the later sections diagram each separate LSA type 🎀.

Each LSA describes a piece of the OSPF routing domain 🗺️. Every router originates a router-LSA, and a network-LSA is advertised for each link by its Designated Router. A router's link-local addresses get advertised to its neighbors in link-LSAs. IPv6 prefixes are advertised in intra-area-prefix-LSAs, inter-area-prefix-LSAs and AS-external-LSAs. The location of specific routers can be advertised across area boundaries in inter-area-router-LSAs 🌍. All LSAs then get flooded throughout the OSPF routing domain. The flooding algorithm is reliable, which means all routers end up with the same collection of LSAs (see Section 3.5 for more on flooding) 🫶. That collection is called the link-state database 🗃️.

From the link-state database, each router builds a shortest path tree with itself as the root. That gives you a routing table (see Section 11 of [Ref1]) 🛣️. For the details of how the routing table gets built, see Section 3.8 🔥.

A.4.1 IPv6 Prefix Representation 🌈

IPv6 addresses are bit strings of length 128 💫. IPv6 routing algorithms, and OSPF for IPv6 in particular, advertise IPv6 address prefixes. IPv6 address prefixes are bit strings whose length ranges between 0 and 128 bits (inclusive) 🧮.

Within OSPF, IPv6 address prefixes are always represented by a combo of three fields: PrefixLength, PrefixOptions, and Address Prefix 🎀. PrefixLength is the length in bits of the prefix. PrefixOptions is an 8-bit field describing various capabilities associated with the prefix (see Section A.4.2). Address Prefix is an encoding of the prefix itself as an even multiple of 32-bit words, padded with zero bits as needed. This encoding consumes (PrefixLength + 31) / 32) 32-bit words 🧸.

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

You can find examples of IPv6 prefix representation in OSPF in Sections A.4.5, A.4.7, A.4.8 and A.4.9 📚.

A.4.1.1 Prefix Options 💅

Each prefix is advertised along with an 8-bit field of capabilities 🍓. These serve as input to the various routing calculations, so they can do things like make certain prefixes get ignored in some cases, or mark them as not readvertisable in others 🙈.

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

                The Prefix Options field

NU-bit: The "no unicast" capability bit. If set, the prefix should be excluded from IPv6 unicast calculations, otherwise it should be included 🚫
LA-bit: The "local address" capability bit. If set, the prefix is actually an IPv6 interface address of the advertising router 🏠
MC-bit: The "multicast" capability bit. If set, the prefix should be included in IPv6 multicast routing calculations, otherwise it should be excluded 📡
P-bit: The "propagate" bit. Set on NSSA area prefixes that should be readvertised at the NSSA area border 📣

A.4.2 The LSA header 🎀

All LSAs begin with a common 20 byte header 💌. This header has enough info to uniquely identify the LSA (LS type, Link State ID, and Advertising Router). Multiple instances of the LSA can exist in the routing domain at the same time, so it's necessary to figure out which instance is more recent. That's handled by checking the LS age, LS sequence number and LS checksum fields, which are also in the LSA header 🕵️‍♀️✨.

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

LS age: The time in seconds since the LSA was originated ⏰
LS type: The LS type field indicates the function performed by the LSA. The high-order three bits of LS type encode generic properties of the LSA, while the remainder (called LSA function code) indicate the LSA's specific functionality. See Section A.4.2.1 for a detailed description of LS type 🏷️
Link State ID: Together with LS type and Advertising Router, uniquely identifies the LSA in the link-state database 🆔
Advertising Router: The Router ID of the router that originated the LSA. For example, in network-LSAs this field is equal to the Router ID of the network's Designated Router 👑
LS sequence number: Detects old or duplicate LSAs. Successive instances of an LSA are given successive LS sequence numbers. See Section 12.1.6 in [Ref1] for more details 🔢
LS checksum: The Fletcher checksum of the complete contents of the LSA, including the LSA header but excluding the LS age field. See Section 12.1.7 in [Ref1] for more details 🧾
length: The length in bytes of the LSA. This includes the 20 byte LSA header 📏

A.4.2.1 LS type

okay so the LS type field tells you what job the LSA is doing 💅 The top three bits are like the LSA's general vibe (generic properties), and the rest is the LSA function code, which is its specific talent ✨

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

The U bit is the "what do I do with this if I don't recognize it?" bit 🙈 Here's how it goes:

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

Next up, the S1 and S2 bits decide the flooding scope, aka how far the LSA gets to spread its tea 🫖🌸

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

Now the LSA function codes 🎀 Their origination and processing are defined elsewhere in this memo, except for the group-membership-LSA (see [Ref7]) and the Type-7-LSA (see [Ref8]). Every function code also comes with a set vibe for the U, S1 and S2 bits, shown below:

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

A.4.3 Router-LSAs

Router-LSAs have LS type equal to 0x2001 🧚 Every router in an area originates one or more router-LSAs, and together they're basically the router's full profile: they describe the state and cost of its interfaces to the area 💖 For how to actually build them, check Section 3.4.3.1. Router-LSAs only get flooded throughout a single area, so they stay in their lane 🦋

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

A single router can originate more than one Router LSA 🌈 They're told apart by their Link-State IDs, which the originating router picks arbitrarily. The Options field and the V, E and B bits should be the same across all Router LSAs from one originator. But if they don't match, the values in the LSA with the lowest Link State ID take precedence 👑 And when a router sends more than one Router LSA, the links get processed as if they were all concatenated into one LSA 🫶

bit V: when set, the router is an endpoint of one or more fully adjacent virtual links that have the described area as Transit area (V is for virtual link endpoint) 🦋
bit E: when set, the router is an AS boundary router (E is for external) ✨
bit B: when set, the router is an area border router (B is for border) 🌸
bit W: when set, the router is a wild-card multicast receiver. When running MOSPF, these routers receive all multicast datagrams, regardless of destination. See Sections 3, 4 and A.2 of [Ref8] for details 💜
Options: the optional capabilities supported by the router, as documented in Section A.2 🎀

Next, each router interface gets its own little entry 💅 The Type field says what kind of interface it is: a transit network, a point-to-point connection to another router, or a virtual link. Everything else in the entry depends on that Type field, so it's giving "choose your own adventure" 🧚

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

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

Metric: the cost of using this router interface, for outbound traffic 🍓
Interface ID: the Interface ID assigned to the interface being described. See Sections 3.1.2 and C.3 🔥
Neighbor Interface ID: the Interface ID the neighbor router (or the attached link's Designated Router, for Type 2 interfaces) has been advertising in hello packets sent on the attached link 💖
Neighbor Router ID: the Router ID the neighbor router (or the attached link's Designated Router, for Type 2 interfaces) 🫶

For Type 2 links, the combination of Neighbor Interface ID and Neighbor Router ID is what lets you find the network-LSA for the attached link in the link-state database 🔍 Iconic teamwork, honestly.

A.4.4 Network-LSAs

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

The distance from the network to all attached routers is zero, which is why the metric fields don't need to be specified in the network-LSA 🧚 For how to construct them, see Section 3.4.3.2 💅

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

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

A.4.5 Inter-Area-Prefix-LSAs ✨

okay so Inter-Area-Prefix-LSAs have LS type 0x2003 💖 they're the IPv6 version of the type 3 summary-LSAs from OSPF for IPv4 (check Section 12.4.3 of [Ref1] if you want the original). area border routers originate them, and they describe routes to IPv6 address prefixes that live in other areas. you get a separate Inter-Area-Prefix-LSA for every single IPv6 address prefix, so no bundling 🙈 if you want the nitty gritty on how they're built, see Section 3.4.3.3.

stub areas can use these LSAs to describe a per-area default route 🌸 this is lowkey the whole point, because default summary routes let stub areas skip flooding a full set of external routes. when you're describing a default summary route, the PrefixLength gets set to 0. iconic 💅

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

Metric 💜 this is the cost of the route, measured in the same units as the interface costs in the router-LSAs. if the Inter-Area-Prefix-LSA is describing a route to a range of addresses (see Section C.2), the cost gets set to the maximum cost to any reachable component of that range. main character energy 👑

PrefixLength, PrefixOptions and Address Prefix 🎀 this is the IPv6 address prefix, represented the way Section A.4.1 explains.

A.4.6 Inter-Area-Router-LSAs 🦋

Inter-Area-Router-LSAs have LS type 0x2004. they're the IPv6 twin of the type 4 summary-LSAs in OSPF for IPv4 (see Section 12.4.3 of [Ref1] again 💅). area border routers create these, and they describe routes to routers in other areas. if you're wondering why we need to advertise where each ASBR is, check out Section 16.4 in [Ref1] 🧚 each LSA describes a route to one single router. for how these get built, see Section 3.4.3.4.

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

Options 🌈 the optional capabilities the router supports, as documented in Section A.2.

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

Destination Router ID ⭐ the Router ID of the router that this LSA describes.

A.4.7 AS-external-LSAs 🌸

AS-external-LSAs have LS type 0x4005 🫶 AS boundary routers originate them, and they describe destinations outside the AS. each LSA describes a route to a single IPv6 address prefix. for how they're constructed, see Section 3.4.3.5.

AS-external-LSAs can also describe a default route, which gets used when there's no specific route to the destination 🙌 when you're describing a default route, the AS-external-LSA's PrefixLength is set to 0.

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

bit E 💅 this is the type of external metric. if bit E is set, the metric is a Type 2 external metric, which means it's treated as larger than any intra-AS path. if bit E is zero, it's a Type 1 external metric, meaning it's expressed in the same units as the link state metric (so the same units as interface cost).

bit F 🔥 if set, a Forwarding Address has been included in the LSA.

bit T ✨ if set, an External Route Tag has been included in the LSA.

Metric 🎀 the cost of this route. how you read it depends on the external type (bit E, above).

PrefixLength, PrefixOptions and Address Prefix 💖 this is the IPv6 address prefix, represented as described in Section A.4.1.

Referenced LS type 🦋 if it's non-zero, an LSA with this LS type is associated with this LSA (see Referenced Link State ID below).

Forwarding address 🌷 a fully qualified IPv6 address (128 bits). it's included in the LSA if and only if bit F has been set. when it's included, data traffic for the advertised destination gets forwarded to this address. it must not be set to the IPv6 Unspecified Address (0:0:0:0:0:0:0:0) 🙈

External Route Tag 🧚 a 32-bit field that can carry extra info between AS boundary routers. see [Ref5] for example usage. it's included in the LSA if and only if bit T has been set.

Referenced Link State ID 🌈 this one's included if and only if the Referenced LS type is non-zero. when it's there, extra info about the advertised external route can be found in the LSA with LS type equal to the "Referenced LS Type", Link State ID equal to the "Referenced Link State ID", and an Advertising Router matching the one in the AS-external-LSA's link state header. this info isn't used by the OSPF protocol itself 🫶 it's just there for AS boundary routers to talk to each other. the exact nature of that info is outside the scope of this specification.

ngl the field order is the part you'll want to memorize 😭 any, all, or none of the Forwarding address, External Route Tag and Referenced Link State ID fields can show up in the AS-external-LSA (depending on bit F, bit T and the Referenced LS type). but whatever's present always goes in this order: Forwarding Address first, then External Route Tag, then Referenced Link State ID. periodt 💜

A.4.8 Link-LSAs 🔗

Okay so Link-LSAs have LS type 0x0008 💖. A router makes a separate Link-LSA for every link it's attached to. They have local-link flooding scope, which means they are never flooded beyond the link they belong to 🙅‍♀️. They have three jobs, and they're all iconic: 1) they hand out the router's link-local address to every other router on the link, 2) they tell those routers which IPv6 prefixes go with the link, and 3) they let the router assert a set of Options bits to pair with the Network-LSA that gets originated for the link 💅.

A link-LSA's Link State ID is set equal to the originating router's Interface ID on the link ✨.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS age             |0|0|0|           8              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Advertising Router                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LS sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum           |             length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Rtr Pri    |                Options                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                Link-local Interface Address                 -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         # prefixes                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PrefixLength | PrefixOptions |             (0)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Address Prefix                         |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PrefixLength | PrefixOptions |             (0)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Address Prefix                         |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

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

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

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

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

A.4.9 Intra-Area-Prefix-LSAs 🦋

Intra-Area-Prefix-LSAs have LS type 0x2009. A router uses them to advertise one or more IPv6 address prefixes that are associated with a) the router itself, b) an attached stub network segment or c) an attached transit network segment. In IPv4, a) and b) were handled through the router's router-LSA, and c) through a network-LSA. But in OSPF for IPv6, all addressing information has been removed from router-LSAs and network-LSAs, which is why the Intra-Area-Prefix-LSA was introduced 🌈.

A router can originate multiple Intra-Area-Prefix-LSAs for each router or transit network. Each one is distinguished by its Link State ID 🔥.

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

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

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

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

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

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

B. Architectural Constants 🌸

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

C. Configurable Constants 🎀

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

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

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

C.1 Global parameters 🌈

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

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

Because the size of the Router ID is smaller than an IPv6 address, it cannot be set to one of the router's IPv6 addresses (as is commonly done for IPv4). Possible Router ID assignment procedures for IPv6 include: a) assign the IPv6 Router ID as one of the router's IPv4 addresses or b) assign IPv6 Router IDs through some local administrative procedure (similar to procedures used by manufacturers to assign product serial numbers) 🍓.

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

C.2 Area parameters ✨

Okay bestie, every router in an area has to agree on that area's configuration 🫶 If two routers disagree, their adjacencies won't form, and then routing and data traffic gets stuck 😭 Here's what you have to configure for an area:

Area ID 🆔 This is a 32-bit number that identifies the area. Area ID 0 is reserved for the backbone 👑
List of address ranges 🦋 Address ranges control which routes get advertised across area boundaries. Each address range has these items:
- [IPv6 prefix, prefix length] describes the collection of IPv6 addresses in that range 💅
- Status is set to either Advertise or DoNotAdvertise. Routing info gets condensed at area borders, so outside the area, at most a single route gets advertised (via an inter-area-prefix-LSA) for each address range. The route is only advertised if the range's Status is Advertise. Unadvertised ranges let you intentionally hide certain networks from other areas 🙈 Status is Advertise by default.
ExternalRoutingCapability 🌸 This decides whether AS-external-LSAs get flooded into and throughout the area. If AS-external-LSAs are excluded, the area is called a "stub" area. Inside a stub area, routing to external destinations is based solely on a default inter-area route. The backbone can't be configured as a stub area, and virtual links can't be configured through stub areas either 💀 For more info, see Section 3.6 of [Ref1].
StubDefaultCost 🍓 If the area is configured as a stub area and the router is itself an area border router, then the StubDefaultCost is the cost of the default inter-area-prefix-LSA that the router should advertise into the area. See Section 12.4.3.1 of [Ref1] for more.

C.3 Router interface parameters 🎀

Some of the configurable router interface parameters (like Area ID, HelloInterval and RouterDeadInterval) actually describe properties of the attached links, so they have to be consistent across every router on that link 🔗 These are the parameters you must configure for a router interface:

IPv6 link-local address 🌈 The IPv6 link-local address for this interface. It may be learned through auto-configuration.
Area ID 🗺️ The OSPF area the attached link belongs to.
Instance ID 🧚 The OSPF protocol instance tied to this OSPF interface. It defaults to 0.
Interface ID 🪪 A 32-bit number that uniquely identifies this interface among this router's interfaces. For example, some implementations can use the MIB-II IfIndex ([Ref3]) for this.
IPv6 prefixes 📦 The list of IPv6 prefixes to associate with the link. These get advertised in intra-area-prefix-LSAs.
Interface output cost(s) 💸 The cost of sending a packet on the interface, expressed in the link state metric. It's advertised as the link cost for this interface in the router's router-LSA. The interface output cost must always be greater than 0.
RxmtInterval ⏱️ The number of seconds between LSA retransmissions for adjacencies on this interface. It's also used when retransmitting Database Description and Link State Request Packets. It should be well over the expected round-trip delay between any two routers on the attached link. Keep it conservative, or you'll get needless retransmissions 😭 Sample value for a local area network: 5 seconds.
InfTransDelay 🚚 The estimated number of seconds it takes to transmit a Link State Update Packet over this interface. LSAs in the update packet must have their age incremented by this amount before transmission. This value should account for the interface's transmission and propagation delays. It must be greater than 0. Sample value for a local area network: 1 second.
Router Priority 👑 An 8-bit unsigned integer. When two routers on a network both try to become Designated Router, the one with the highest Router Priority wins. If it's still tied, the router with the highest Router ID wins. A router whose Router Priority is 0 is ineligible to become Designated Router on the attached link. Router Priority is only configured for interfaces to broadcast and NBMA networks.
HelloInterval 👋 The number of seconds between the Hello Packets this router sends on the interface. This value is advertised in the router's Hello Packets. It must be the same for all routers on a common link. A smaller HelloInterval means topology changes get detected faster, but more OSPF routing protocol traffic follows ✨ Sample value for an X.25 PDN: 30 seconds. Sample value for a local area network (LAN): 10 seconds.
RouterDeadInterval 💤 After a router stops hearing its neighbor's Hello Packets, this is how many seconds pass before its neighbors declare it down. It's also advertised in the router's Hello Packets, in their RouterDeadInterval field. It should be some multiple of the HelloInterval (say 4). This value also has to be the same for all routers on a common link.

C.4 Virtual link parameters 🌉

Virtual links are how you restore or boost backbone connectivity 💪 You can configure them between any pair of area border routers that have interfaces to a common (non-backbone) area. The virtual link shows up as an unnumbered point-to-point link in the backbone's graph. It must be configured on both of the area border routers.

In router-LSAs for the backbone, a virtual link looks like a separate router interface to the backbone, so it has most of the parameters a router interface has (see Section C.3). Virtual links don't have link-local addresses. Instead, they use one of the router's global-scope or site-local IPv6 addresses as the IP source in the OSPF protocol packets it sends along the virtual link 🫶 Router Priority isn't used on virtual links. Interface output cost isn't configured on virtual links either. It's dynamically set to the cost of the intra-area path between the two endpoint routers ✨ The RxmtInterval must be configured, and it should be well over the expected round-trip delay between the two routers. This can be hard to estimate for a virtual link, so it's better to go too large than too small 💅

A virtual link is defined by two configurable parameters: the Router ID of the virtual link's other endpoint, and the (non-backbone) area the virtual link runs through. That area is called the virtual link's Transit area. Virtual links can't be configured through stub areas 🚫

C.5 NBMA network parameters 🌐

OSPF treats an NBMA network pretty much like a broadcast network 💖 Since there may be lots of routers attached, a Designated Router gets selected for the network. That Designated Router then originates a network-LSA, which lists all the routers attached to the NBMA network.

Because NBMA networks don't have broadcast capabilities, you may need configuration parameters for Designated Router selection. These only need to be configured on routers that are eligible to become Designated Router (meaning their Router Priority for the network isn't zero), and only if no automatic procedure for discovering neighbors exists 🔍

List of all other attached routers 📋 The list of all other routers attached to the NBMA network. Each router is configured with its Router ID and IPv6 link-local address on the network. For each router listed, you also have to define whether that router is eligible to become Designated Router. When an interface to an NBMA network comes up, the router sends Hello Packets only to neighbors eligible to become Designated Router, until it discovers the identity of the Designated Router 🧭
PollInterval 🐢 If a neighboring router has gone inactive (no Hello Packets seen for RouterDeadInterval seconds), you may still need to send Hello Packets to that dead neighbor. These go out at the reduced rate of PollInterval, which should be much larger than HelloInterval. Sample value for a PDN X.25 network: 2 minutes.

C.6 Point-to-MultiPoint network parameters 🦋

On Point-to-MultiPoint networks, you may need to configure the set of neighbors that are directly reachable over the network. Each neighbor is configured with its Router ID and IPv6 link-local address on the network. Designated Routers aren't elected on Point-to-MultiPoint networks, so the Designated Router eligibility of configured neighbors is undefined 🤷‍♀️

C.7 Host route parameters 🏠

Host prefixes get advertised in intra-area-prefix-LSAs. They can indicate internal router addresses, router interfaces to point-to-point networks, looped router interfaces, or IPv6 hosts directly connected to the router (for example, via a PPP connection) 🔌 For each host directly connected to the router, you must configure these items:

Host IPv6 prefix 🎯 The IPv6 prefix that belongs to the host.
Cost of link to host 💰 The cost of sending a packet to the host, in terms of the link state metric. Honestly though, the host probably has only a single connection to the internet, so the configured cost(s) often don't matter (they won't affect routing) 😂
Area ID 🗺️ The OSPF area the host's prefix belongs to.

Security Considerations 🔐

When OSPF runs over IPv6, it relies on the IP Authentication Header (see [Ref19]) and the IP Encapsulating Security Payload (see [Ref20]) to keep routing exchanges integral and authenticated/confidential 🛡️

Most OSPF implementations will run on systems that support multiple protocols, and many of those have their own independent security assumptions and domains 👀 When IPSEC is used to protect OSPF packets, it's really important for the implementation to check the IPSEC SA and the local SA database, so it can make sure the packet comes from a source THAT IS TRUSTED FOR OSPF PURPOSES. > No skipping this one, bestie. A packet that skips the check could come from anywhere 😱

Authors' Addresses 💌

Rob Coltun
Siara Systems
300 Ferguson Drive
Mountain View, CA 94043

Phone: (650) 390-9030
EMail: rcoltun@siara.com


Dennis Ferguson
Juniper Networks
385 Ravendale Drive
Mountain View, CA  94043

Phone: +1 650 526 8004
EMail: dennis@juniper.com


John Moy
Sycamore Networks, Inc.
10 Elizabeth Drive
Chelmsford, MA 01824

Phone: (978) 367-2161
Fax:   (978) 250-3350
EMail: jmoy@sycamorenet.com

Full Copyright Statement 💖

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 🦋

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💅

Acknowledgement 🌸

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

📦 where this page comes from

ietf: rfc2740 1999-12
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms