RFC 5340
OSPF for IPv6
OSPF for IPv6 ✨
okay bestie, so this is RFC 5340, titled OSPF for IPv6 🦋 It's a Standards Track document from the Network Working Group, and it came out in July 2008. It obsoletes RFC 2740, so it's the glow-up that replaces that one 💅 The authors are R. Coltun (Acoustra Productions), D. Ferguson (Juniper Networks), J. Moy (Sycamore Networks, Inc), and A. Lindem, Ed. (Redback Networks) 🫶
Status of This Memo 📜
this one is an Internet standards track protocol for the whole Internet community, and it's asking for discussion and suggestions to make it better 🌸 if you want to know where this protocol stands in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🧚 distribution of this memo is unlimited, so share it with everyone 💖
Abstract 🎀
this doc describes the changes needed to make OSPF work with version 6 of the Internet Protocol (IPv6) ✨ the core OSPF mechanisms (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) are still the same, no cap 🫶 but some things had to change, either because IPv4 and IPv6 handle protocol semantics differently, or just because IPv6 addresses are way bigger 😭 these changes mean the protocol version goes from version 2 to version 3. OSPF for IPv6 is also called OSPF version 3 (OSPFv3) 👑
the big changes are these: addressing semantics got removed from OSPF packets and the basic Link State Advertisements (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 removed from OSPF itself. It now leans on IPv6's Authentication Header and Encapsulating Security Payload (ESP) instead 🔥
even with the bigger addresses, most OSPFv3 packets are almost as compact as the OSPF for IPv4 ones, which is iconic 🍓 most of the fields and packet-size limits from OSPF for IPv4 got loosened up, and option handling is more flexible too 💜
and yes, all of OSPF for IPv4's optional capabilities are supported here too, including demand circuit support and Not-So-Stubby Areas (NSSAs) 🙈
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Differences from OSPF for IPv4 . . . . . . . . . . . . . . . . 5
2.1. Protocol Processing Per-Link, Not Per-Subnet . . . . . . . 5
2.2. Removal of Addressing Semantics . . . . . . . . . . . . . 5
2.3. Addition of Flooding Scope . . . . . . . . . . . . . . . . 6
2.4. Explicit Support for Multiple Instances per Link . . . . . 6
2.5. Use of Link-Local Addresses . . . . . . . . . . . . . . . 7
2.6. Authentication Changes . . . . . . . . . . . . . . . . . . 7
2.7. Packet Format Changes . . . . . . . . . . . . . . . . . . 8
2.8. LSA Format Changes . . . . . . . . . . . . . . . . . . . . 9
2.9. Handling Unknown LSA Types . . . . . . . . . . . . . . . . 10
2.10. Stub/NSSA Area Support . . . . . . . . . . . . . . . . . . 11
2.11. Identifying Neighbors by Router ID . . . . . . . . . . . . 11
3. Differences with RFC 2740 . . . . . . . . . . . . . . . . . . 11
3.1. Support for Multiple Interfaces on the Same Link . . . . . 11
3.2. Deprecation of MOSPF for IPv6 . . . . . . . . . . . . . . 12
3.3. NSSA Specification . . . . . . . . . . . . . . . . . . . . 12
3.4. Stub Area Unknown LSA Flooding Restriction Deprecated . . 12
3.5. Link LSA Suppression . . . . . . . . . . . . . . . . . . . 12
3.6. LSA Options and Prefix Options Updates . . . . . . . . . . 13
3.7. IPv6 Site-Local Addresses . . . . . . . . . . . . . . . . 13
4. Implementation Details . . . . . . . . . . . . . . . . . . . . 13
4.1. Protocol Data Structures . . . . . . . . . . . . . . . . . 14
4.1.1. The Area Data Structure . . . . . . . . . . . . . . . 15
4.1.2. The Interface Data Structure . . . . . . . . . . . . . 15
4.1.3. The Neighbor Data Structure . . . . . . . . . . . . . 16
4.2. Protocol Packet Processing . . . . . . . . . . . . . . . . 17
4.2.1. Sending Protocol Packets . . . . . . . . . . . . . . . 17
4.2.1.1. Sending Hello Packets . . . . . . . . . . . . . . 18
4.2.1.2. Sending Database Description Packets . . . . . . . 19
4.2.2. Receiving Protocol Packets . . . . . . . . . . . . . . 19
4.2.2.1. Receiving Hello Packets . . . . . . . . . . . . . 21
4.3. The Routing table Structure . . . . . . . . . . . . . . . 22
4.3.1. Routing Table Lookup . . . . . . . . . . . . . . . . . 23
4.4. Link State Advertisements . . . . . . . . . . . . . . . . 23
4.4.1. The LSA Header . . . . . . . . . . . . . . . . . . . . 23
4.4.2. The Link-State Database . . . . . . . . . . . . . . . 24
4.4.3. Originating LSAs . . . . . . . . . . . . . . . . . . . 25
4.4.3.1. LSA Options . . . . . . . . . . . . . . . . . . . 27
4.4.3.2. Router-LSAs . . . . . . . . . . . . . . . . . . . 27
4.4.3.3. Network-LSAs . . . . . . . . . . . . . . . . . . . 29
4.4.3.4. Inter-Area-Prefix-LSAs . . . . . . . . . . . . . . 30
4.4.3.5. Inter-Area-Router-LSAs . . . . . . . . . . . . . . 31
4.4.3.6. AS-External-LSAs . . . . . . . . . . . . . . . . . 32
4.4.3.7. NSSA-LSAs . . . . . . . . . . . . . . . . . . . . 33
4.4.3.8. Link-LSAs . . . . . . . . . . . . . . . . . . . . 34
4.4.3.9. Intra-Area-Prefix-LSAs . . . . . . . . . . . . . . 36
4.4.4. Future LSA Validation . . . . . . . . . . . . . . . . 40
4.5. Flooding . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5.1. Receiving Link State Update Packets . . . . . . . . . 40
4.5.2. Sending Link State Update Packets . . . . . . . . . . 41
4.5.3. Installing LSAs in the Database . . . . . . . . . . . 43
4.6. Definition of Self-Originated LSAs . . . . . . . . . . . . 43
4.7. Virtual Links . . . . . . . . . . . . . . . . . . . . . . 44
4.8. Routing Table Calculation . . . . . . . . . . . . . . . . 44
4.8.1. Calculating the Shortest-Path Tree for an Area . . . . 45
4.8.2. The Next-Hop Calculation . . . . . . . . . . . . . . . 44
4.8.3. Calculating the Inter-Area Routes . . . . . . . . . . 47
4.8.4. Examining Transit Areas' Summary-LSAs . . . . . . . . 48
4.8.5. Calculating AS External and NSSA Routes . . . . . . . 48
4.9. Multiple Interfaces to a Single Link . . . . . . . . . . . 48
4.9.1. Standby Interface State . . . . . . . . . . . . . . . 50
5. Security Considerations . . . . . . . . . . . . . . . . . . . 52
6. Manageability Considerations . . . . . . . . . . . . . . . . . 52
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
7.1. MOSPF for OSPFv3 Deprecation IANA Considerations . . . . . 53
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.1. Normative References . . . . . . . . . . . . . . . . . . . 55
9.2. Informative References . . . . . . . . . . . . . . . . . . 56
Appendix A. OSPF Data Formats . . . . . . . . . . . . . . . . . . 57
A.1. Encapsulation of OSPF Packets . . . . . . . . . . . . . . 57
A.2. The Options Field . . . . . . . . . . . . . . . . . . . . 58
A.3. OSPF Packet Formats . . . . . . . . . . . . . . . . . . . 60
A.3.1. The OSPF Packet Header . . . . . . . . . . . . . . . . 60
A.3.2. The Hello Packet . . . . . . . . . . . . . . . . . . . 62
A.3.3. The Database Description Packet . . . . . . . . . . . 63
A.3.4. The Link State Request Packet . . . . . . . . . . . . 65
A.3.5. The Link State Update Packet . . . . . . . . . . . . . 66
A.3.6. The Link State Acknowledgment Packet . . . . . . . . . 67
A.4. LSA Formats . . . . . . . . . . . . . . . . . . . . . . . 68
A.4.1. IPv6 Prefix Representation . . . . . . . . . . . . . . 69
A.4.1.1. Prefix Options . . . . . . . . . . . . . . . . . . 69
A.4.2. The LSA Header . . . . . . . . . . . . . . . . . . . . 70
A.4.2.1. LSA Type . . . . . . . . . . . . . . . . . . . . . 72
A.4.3. Router-LSAs . . . . . . . . . . . . . . . . . . . . . 73
A.4.4. Network-LSAs . . . . . . . . . . . . . . . . . . . . . 76
A.4.5. Inter-Area-Prefix-LSAs . . . . . . . . . . . . . . . . 77
A.4.6. Inter-Area-Router-LSAs . . . . . . . . . . . . . . . . 78
A.4.7. AS-External-LSAs . . . . . . . . . . . . . . . . . . . 79
A.4.8. NSSA-LSAs . . . . . . . . . . . . . . . . . . . . . . 82
A.4.9. Link-LSAs . . . . . . . . . . . . . . . . . . . . . . 82
A.4.10. Intra-Area-Prefix-LSAs . . . . . . . . . . . . . . . . 84
Appendix B. Architectural Constants . . . . . . . . . . . . . . . 86
Appendix C. Configurable Constants . . . . . . . . . . . . . . . 86
C.1. Global Parameters . . . . . . . . . . . . . . . . . . . . 86
C.2. Area Parameters . . . . . . . . . . . . . . . . . . . . . 87
C.3. Router Interface Parameters . . . . . . . . . . . . . . . 88
C.4. Virtual Link Parameters . . . . . . . . . . . . . . . . . 90
C.5. NBMA Network Parameters . . . . . . . . . . . . . . . . . 91
C.6. Point-to-Multipoint Network Parameters . . . . . . . . . . 92
C.7. Host Route Parameters . . . . . . . . . . . . . . . . . . 921. Introduction ✨
so this section is the warm-up 🌸 it says the same thing as the abstract: OSPF for IPv6 changes the protocol so it can handle IPv6, the fundamental stuff (flooding, DR election, areas, SPF calculations, etc.) stays put, and the protocol version bumps from 2 to 3 🧚 OSPF for IPv6 is also called OSPF version 3 (OSPFv3) 💅
the doc is laid out like this 🎀 Section 2 explains the differences between OSPF for IPv4 (OSPF version 2) and OSPF for IPv6 (OSPF version 3) in detail. Section 3 covers the differences between RFC 2740 and this document. Section 4 gives the implementation details for all the changes. Appendix A has the OSPF for IPv6 packet and Link State Advertisement (LSA) formats 📦 Appendix B lists the OSPF architectural constants, and Appendix C describes the configuration parameters 💜
1.1. Requirements Notation 🔑
okay, the caps words are a whole thing, so pay attention 👀 the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-KEYWORDS] 🫶
1.2. Terminology
okay so this doc borrows words from BOTH the OSPF for IPv4 spec ([OSPFV2]) and the IPv6 protocol specs ([IPV6]) 💅 and honestly? it's a mixed bag 🙈. most terms that OSPF and IPv6 share basically mean the same thing (interfaces, for example) ✨. but there are a few clashes. IPv6 uses "link" kinda like how IPv4 OSPF uses "subnet" or "network", so we went with IPv6's "link" wording 🦋. "Link" replaces OSPF's "subnet" and "network" in most places in this doc, although OSPF's network-LSA stays exactly the same (and, possibly unfortunately, a new link-LSA got created too 💀).
the names of some OSPF LSAs changed as well. check Section 2.8 for the deets 👀.
in this doc, an OSPF instance is a separate protocol instance with its own protocol data structures (areas, interfaces, neighbors), its own link-state database, protocol state machines, and protocol processing (SPF calculation, for example) 🧚.
2. Differences from OSPF for IPv4
most of the algorithms from OSPF for IPv4 [OSPFV2] carried over into OSPF for IPv6 🎀. some changes were still needed, either because IPv4 and IPv6 handle protocol semantics differently, or just to deal with IPv6's much bigger addresses 📏.
the subsections below spell out the differences between this doc and [OSPFV2] 🌸.
2.1. Protocol Processing Per-Link, Not Per-Subnet
IPv6 defines a link as "a communication facility or medium over which nodes can communicate at the link layer" ([IPV6]). interfaces connect to links. multiple IPv6 subnets can be assigned to one link, and two nodes can talk directly over a single link even if they don't share a common IPv6 subnet (IPv6 prefix) 🔗.
so OSPF for IPv6 runs per-link instead of IPv4's per-IP-subnet vibe 💜. the terms "network" and "subnet" from the IPv4 OSPF spec ([OSPFV2]) should generally be replaced by link. and an OSPF interface now connects to a link instead of an IP subnet ✨.
this change affects how OSPF protocol packets get received, what goes in Hello packets, and what goes in network-LSAs 📦.
2.2. Removal of Addressing Semantics
in OSPF for IPv6, addressing semantics got removed from the OSPF protocol packets and the main LSA types, leaving a network-protocol-independent core 🧼. specifically:
- 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 remain 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 had been identified by an IPv4 address on broadcast, NBMA (Non-Broadcast Multi-Access), and point-to-multipoint links.
2.3. Addition of Flooding Scope
flooding scope for LSAs got generalized and is now explicitly coded in the LSA's LS type field 🌊. there are now three separate flooding scopes for LSAs:
- Link-local scope. LSA is only flooded on the local link and no further. Used for the new link-LSA. See Section 4.4.3.8 for details.
- Area scope. LSA is only flooded throughout a single OSPF area. Used for router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, and intra-area-prefix-LSAs.
- AS scope. LSA is flooded throughout the routing domain. Used for AS-external-LSAs. A router that originates AS scoped LSAs is considered an AS Boundary Router (ASBR) and will set its E-bit in router-LSAs for regular areas.
2.4. Explicit Support for Multiple Instances per Link
OSPF now supports running multiple OSPF protocol instances on a single link 🧑🤝🧑. for example, this may be required on a NAP segment shared between several providers 🏢. providers may be supporting separate OSPF routing domains that want to stay separate, even though they have one or more physical network segments (i.e., links) in common 🙅♀️. in OSPF for IPv4, this was handled in a haphazard fashion using the authentication fields in the OSPF for IPv4 header 😵.
another use for running multiple OSPF instances: if you want, for one reason or another, to have a single link belong to two or more OSPF areas 🗺️.
support for multiple protocol instances on a link is done with an "Instance ID" contained in the OSPF packet header and in the OSPF interface data structures 🆔. the Instance ID solely affects the reception of OSPF packets, and it applies to normal OSPF interfaces and virtual links 📬.
2.5. Use of Link-Local Addresses
IPv6 link-local addresses are for use on a single link, for purposes like neighbor discovery and auto-configuration 🏠. IPv6 routers do not forward IPv6 datagrams that have link-local source addresses [IP6ADDR]. link-local unicast addresses are assigned from the IPv6 address range FE80/10.
OSPF for IPv6 assumes that each router has been assigned link-local unicast addresses on each of the router's attached physical links [IP6ADDR]. on all OSPF interfaces except virtual links, OSPF packets are sent using the interface's associated link-local unicast address as the source address 📤. a router learns the link-local addresses of all other routers attached to its links and uses these addresses as next-hop information during packet forwarding 🧭.
on virtual links, a global scope IPv6 address MUST be used as the source address for OSPF protocol packets. 🌍
link-local addresses appear in OSPF link-LSAs (see Section 4.4.3.8). however, link-local addresses are not allowed in other OSPF LSA types. in particular, link-local addresses MUST NOT be advertised in inter-area-prefix-LSAs (Section 4.4.3.4), AS-external-LSAs (Section 4.4.3.6), NSSA-LSAs (Section 4.4.3.7), or intra-area-prefix-LSAs (Section 4.4.3.9). no link-local addresses in those, bestie, no exceptions 🚫
2.6. Authentication Changes
in OSPF for IPv6, authentication has been removed from the OSPF protocol 🔐. the AuType and Authentication fields have been removed from the OSPF packet header, and all authentication-related fields have been removed from the OSPF area and interface data structures 🗑️.
when running over IPv6, OSPF relies on the IP Authentication Header (see [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) as described in [OSPFV3-AUTH] to ensure integrity and authentication/confidentiality of routing exchanges 🛡️.
protection of OSPF packet exchanges against accidental data corruption is provided by the standard IPv6 Upper-Layer checksum (as described in Section 8.1 of [IPV6]), which covers the entire OSPF packet and the prepended IPv6 pseudo-header (see Appendix A.3.1) ✅.
2.7. Packet Format Changes
OSPF for IPv6 runs directly over IPv6 🚀. aside from this, all addressing semantics have been removed from the OSPF packet headers, making it essentially "network-protocol-independent" 🌍. all addressing information is now contained in the various LSA types only 📍.
in detail, the changes in OSPF packet format consist of the following:
- The OSPF version number has been incremented from 2 to 3. 🔢
- The
Optionsfield in Hello packets and Database Description packets has been expanded to 24 bits. - The
AuthenticationandAuTypefields have been removed from the OSPF packet header (see Section 2.6). - The Hello packet now contains no address information at all. rather, it now includes an
Interface IDthat the originating router has assigned to uniquely identify (among its own interfaces) its interface to the link. thisInterface IDwill be used as the network-LSA's Link State ID if the router becomes the Designated Router on the link. 🆔 - Two Options bits, the
R-bitand theV6-bit, have been added to theOptionsfield for processing router-LSAs during the SPF calculation (see Appendix A.2). if theR-bitis clear, an OSPF speaker can participate in OSPF topology distribution without being used to forward transit traffic. this can be used in multi-homed hosts that want to participate in the routing protocol. theV6-bitspecializes theR-bit: if theV6-bitis clear, an OSPF speaker can participate in OSPF topology distribution without being used to forward IPv6 datagrams. if theR-bitis set and theV6-bitis 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" that allows multiple OSPF protocol instances to be run on a single link (see Section 2.4). 🫶
2.8. LSA Format Changes ✨
okay so the LSA header, router-LSAs, and network-LSAs have ALL their addressing semantics removed 💅 zero address stuff in there anymore. These two now describe the routing domain's topology in a way that doesn't care which network protocol you're running 🦋. New LSAs show up to carry the IPv6 address info and the data needed for next-hop resolution 🧚. Some of IPv4's LSA names also got a glow-up so they match each other better 💖
Here's the full tea on what changed in the LSA format 👀
- The Options field is gone from the LSA header 💀. It got expanded to 24 bits and moved into the body of router-LSAs, network-LSAs, inter-area-router-LSAs, and link-LSAs. See Appendix A.2 for details.
- The LSA Type field grew to 16 bits (it took over the old Options space) 📈. Its upper three bits now encode flooding scope and how unknown LSA types get handled (see Section 2.9).
- Addresses in LSAs are now
[prefix, prefix length]instead of[address, mask](see Appendix A.4.1) 🎀. The default route is a prefix with length 0. - Router-LSAs and network-LSAs have no address information now 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. no skipping, bestie 🙅♀️
- A new LSA called the link-LSA has been introduced 🌈. Link-LSAs have link-local flooding scope, so they are never flooded beyond the link they're associated with. They have three jobs: 1) they give all the other routers on the link the router's link-local address, 2) they tell those routers which list of IPv6 prefixes to associate with the link, and 3) they let the router advertise a collection of Options bits to associate with the network-LSA that will be originated for the link. See Section 4.4.3.8 for details.
- In IPv4, the router-LSA carries a router's IPv4 interface addresses, which is basically the IPv4 version of link-local addresses 🔍. These only get used when calculating next hops during the OSPF routing calculation (see Section 16.1.1 of [OSPFV2]), so they don't need to be flooded past the local link. That's why using link-LSAs to distribute them is more efficient ⚡. Also, link-local addresses can't always be learned from Hellos. On NBMA links, next-hop routers don't necessarily exchange Hellos. Instead, they learn about each other through the Designated Router (DR) 🤝.
- 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 got renamed "inter-area-prefix-LSAs" 🏷️. Type-4 summary LSAs got renamed "inter-area-router-LSAs".
- The Link State ID in inter-area-prefix-LSAs, inter-area-router-LSAs, NSSA-LSAs, and AS-external-LSAs has lost its addressing semantics 🫥. Now it only identifies individual pieces of the Link State Database. Any addresses or Router IDs it used to carry are now in the LSA bodies instead.
- Network-LSAs and link-LSAs are the only LSAs whose Link State ID carries extra meaning 🦋. For these, the Link State ID is always the Interface ID of the originating router on the link being described. That's also why they're the only LSAs whose size can't 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 🌷. It carries all the IPv6 prefix info that IPv4 puts in router-LSAs and network-LSAs. See Section 4.4.3.9 for details.
- Including a forwarding address or external route tag in AS-external-LSAs is now optional 🙌. AS-external-LSAs can also reference another LSA to include extra route attributes that sit outside the scope of the OSPF protocol. For example, this reference could be used to attach BGP path attributes to external routes 🛣️.
2.9. Handling Unknown LSA Types 🧩
Unknown LSA types are way more flexible now 🙌. Depending on the LS type, they either get treated as having link-local flooding scope, or they get stored and flooded as if they were understood. This behavior is coded explicitly in the LSA Handling bit of the link state header's LS type field (see the U-bit in Appendix A.4.2.1).
IPv4 OSPF just discards unknown types, and that's a no-go here 🚫. The reason is the desire to mix router capabilities on a single link. Discarding unknown types causes problems when the Designated Router supports fewer options than the other routers on the link 😬.
2.10. Stub/NSSA Area Support 🏝️
In OSPF for IPv4, stub and NSSA areas were built to keep the link-state database and routing table sizes small for the areas' internal routers 🌿. That lets routers with minimal resources join even very large OSPF routing domains 💪.
The stub and NSSA concept sticks around in OSPF for IPv6 🫶. Of the mandatory LSA types, stub areas carry only router-LSAs, network-LSAs, inter-area-prefix-LSAs, link-LSAs, and intra-area-prefix-LSAs. NSSA areas are limited to these same types plus, of course, NSSA-LSAs. This is the IPv6 version of the LSA types carried in IPv4 stub areas, which were router-LSAs, network-LSAs, and type 3 summary-LSAs. For NSSA areas in IPv4, you also get the stub area types and NSSA-LSAs 🍓.
2.11. Identifying Neighbors by Router ID 🆔
In OSPF for IPv6, neighboring routers on a given link are always identified by their OSPF Router ID 💜. IPv4 is different. There, neighbors on point-to-point networks and virtual links are identified by Router IDs, while neighbors on broadcast, NBMA, and point-to-multipoint links are identified by their IPv4 interface addresses.
This change affects how OSPF packets get received (see Section 8.2 of [OSPFV2]), how neighbors get looked up (Section 10 of [OSPFV2]), and how Hello packets get received (Section 10.5 of [OSPFV2]) 📬.
The Router ID of 0.0.0.0 is reserved, so it SHOULD NOT be used 🚫.
3. Differences with RFC 2740 🔄
OSPFv3 implementations based on RFC 2740 will fully interoperate with implementations based on this specification 🤝. There are some protocol additions and changes, though, and they're all backward compatible 💖.
3.1. Support for Multiple Interfaces on the Same Link 🔌
RFC 2740 only partially specified this feature 😵. The level of detail wasn't enough to actually implement it. Section 4.9 has the additions and clarifications you need to implement it. They're fully compatible with RFC 2740 ✅.
3.2. Deprecation of MOSPF for IPv6 🪦
RFC 2740 only partially specified this feature too, and the level of detail wasn't enough to implement it 🙃. There are no known implementations. Multicast Extensions to OSPF (MOSPF) support and its attendant protocol fields have been deprecated from OSPFv3 💀. Refer to Section 4.4.3.2, Section 4.4.3.4, Section 4.4.3.6, Section 4.4.3.7, Appendix A.2, Appendix A.4.2.1, Appendix A.4.3, Appendix A.4.1.1, and Section 7.1.
3.3. NSSA Specification 📘
RFC 2740 only partially specified this one as well 😅. The level of detail wasn't enough to implement the function. This document includes an NSSA specification that's unique to OSPFv3. Together with [NSSA], this specification gives you enough to implement it. Refer to Section 4.8.5, Appendix A.4.3, Appendix A.4.8, and [NSSA] 📚.
3.4. Stub Area Unknown LSA Flooding Restriction Deprecated 🚫🌊
In RFC 2740 [OSPFV3], flooding of unknown LSAs was restricted within stub and NSSA areas. The text describing that restriction is quoted below:
However, unlike in IPv4, IPv6 allows LSAs with unrecognized LS types to be labeled "Store and flood the LSA, as if type understood" (see the U-bit in Appendix A.4.2.1). Uncontrolled introduction of such LSAs could cause a stub area's link-state database to grow larger than its component routers' capacities. To guard against this, the following rule regarding stub areas has been established: an LSA whose LS type is unrecognized can only be flooded into/throughout a stub area if both a) the LSA has area or link-local flooding scope and b) the LSA has U-bit set to 0. See Section 3.5 for details.
This restriction has been deprecated 🎉. OSPFv3 routers will flood link and area scope LSAs whose LS type is unrecognized and whose U-bit is set to 1 throughout stub and NSSA areas. The only backward-compatibility issue is that OSPFv3 routers still supporting the restriction may not propagate newly defined LSA types 🤷♀️.
3.5. Link LSA Suppression 🤫
The LinkLSASuppression interface configuration parameter has been added 🧁. If LinkLSASuppression is configured for an interface and the interface type is not broadcast or NBMA, origination of the link-LSA may be suppressed. The LinkLSASuppression interface configuration parameter is described in Appendix C.3. Section 4.8.2 and Section 4.4.3.8 were updated to reflect how the parameter is used 🔧.
3.6. LSA Options and Prefix Options Updates 🧾
The LSA Options and Prefix Options fields got updated to reflect recent protocol additions ✨. Bits related to MOSPF have been deprecated, Options field bits common with OSPFv2 have been reserved, and the DN-bit has been added to the prefix-options 💅. Refer to Appendix A.2 and Appendix A.4.1.1.
3.7. IPv6 Site-Local Addresses 🙈
All references to IPv6 site-local addresses have been removed 👋.
4. Implementation Details ✨
Okay so going from IPv4 to IPv6, the basic OSPF mechanisms basically stay the same as what's in [OSPFV2] 💅 Section 4 of [OSPFV2] has the quick recap. Both IPv6 and IPv4 keep a link-state database made of LSAs, and adjacent routers keep it in sync. The first sync happens during the Database Exchange, which means trading Database Description, Link State Request, and Link State Update packets. After that, the sync is kept up through flooding with Link State Update and Link State Acknowledgment packets 🔄 Both versions also use OSPF Hello packets to find neighbors and keep those relationships alive, and to elect Designated Routers and Backup Designated Routers on broadcast and NBMA links 🫶 The decision about which neighbor relationships become adjacencies, the basic ideas behind inter-area routing, importing external info in AS-external-LSAs, and the routing calculations are all the same too. Iconic consistency 👑
In particular, these IPv4 OSPF features from [OSPFV2] are completely unchanged for IPv6:
- Both IPv4 and IPv6 use the OSPF packet types from Section 4.3 of [OSPFV2]: Hello, Database Description, Link State Request, Link State Update, and Link State Acknowledgment packets. Some of them changed their format a bit (Hello packets, for example), but what each packet type does is still the same 🎀
- The system requirements for an OSPF implementation are unchanged. The one difference is that OSPF for IPv6 needs an IPv6 protocol stack (from the network layer on down), since it runs directly over the IPv6 network layer 🌸
- Discovering and maintaining neighbor relationships, and selecting and establishing adjacencies, work the same way. That includes electing the Designated Router and Backup Designated Router on broadcast and NBMA links. You can read about these in Sections 7, 7.1, 7.2, 7.3, 7.4, and 7.5 of [OSPFV2] 📚
- The link types (or equivalently, interface types) OSPF supports are unchanged: 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, stay unchanged. Those are in Sections 9.1, 9.2, 9.3, and 9.4 of [OSPFV2] 🧚
- The neighbor state machine, including the list of OSPF neighbor states and events, is unchanged. Check Sections 10.1, 10.2, 10.3, and 10.4 of [OSPFV2] 💜
- Aging of the link-state database, plus flushing LSAs out of the routing domain through the premature aging process, is unchanged from Sections 14 and 14.1 of [OSPFV2] ⭐
However, some OSPF protocol mechanisms have changed, as covered back in Section 2 of this document 👀 The following subsections explain those changes in detail and point back to the right parts of [OSPFV2].
The following subsections give you a recipe for turning an IPv4 OSPF implementation into an IPv6 OSPF implementation. It's giving step-by-step glow-up 🍓
4.1. Protocol Data Structures
The major OSPF data structures are the same for 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 [OSPFV2], with this twist:
- All LSAs with a known LS type and AS flooding scope show up in the top-level data structure, instead of living under a specific area or link. AS-external-LSAs are the only LSAs defined by this specification that have AS flooding scope. LSAs with an unknown LS type, U-bit set to 1 (flood even when unrecognized), and AS flooding scope also go in the top-level data structure 🌈
4.1.1. The Area Data Structure
The IPv6 area data structure has every element defined for IPv4 areas in Section 6 of [OSPFV2]. On top of that, all LSAs of a known type with area flooding scope are stored in the IPv6 area data structure. That always includes router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, and intra-area-prefix-LSAs. LSAs with an unknown LS type, U-bit set to 1 (flood even when unrecognized), and area scope also go in the area data structure. And NSSA-LSAs get included in an NSSA area's data structure too 🏡
4.1.2. The Interface Data Structure
In OSPF for IPv6, an interface connects a router to a link. The IPv6 interface structure modifies the IPv4 interface structure (defined in Section 9 of [OSPFV2]) like this:
Interface ID
- Every interface gets an Interface ID, which uniquely identifies the interface within the router. For example, some implementations MAY be able to use the MIB-II IfIndex ([INTFMIB]) as the Interface ID. The Interface ID shows up in Hello packets sent out the interface, in the link-local-LSA the router originates for the attached link, and in the router-LSA originated by the router-LSA for the associated area. It also serves as the Link State ID for the network-LSA that the router will originate for the link if the router is elected Designated Router. The Interface ID for a virtual link is independent of the Interface ID of the outgoing interface it traverses in the transit area. 🆔
Instance ID
- Every interface gets an Instance ID. This should default to 0. You only need a value other than 0 on links that contain multiple separate communities of OSPF routers. For example, say there are two communities of routers on one ethernet segment that you want to keep separate. The first community gets an Instance ID of 0, and all its routers use 0 as the Instance ID for their interfaces on the ethernet segment. The other routers' interfaces on that segment get an Instance ID of 1. The OSPF transmit and receive processing (see Section 4.2) then keeps the two communities separate 🧩
List of LSAs with link-local scope
- All LSAs with link-local scope that were originated or flooded on the link belong to the interface structure connected to that link. This includes the collection of the link's link-LSAs 🔗
IP interface address
- For IPv6, the IPv6 address in the source of OSPF packets sent on the interface is almost always a link-local address. The one exception is virtual links, which MUST use one of the router's own global IPv6 addresses as the IP interface address 🌍
List of link prefixes
- You can configure a list of IPv6 prefixes for the attached link. The router advertises these in link-LSAs, so the link's Designated Router can advertise them in intra-area-prefix-LSAs 📣
In OSPF for IPv6, each router interface has a single metric representing the cost of sending packets on it. OSPF for IPv6 also relies on the IP Authentication Header (see [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]), as described in [OSPFV3-AUTH], to ensure integrity and authentication/confidentiality of routing exchanges. Because of that, AuType and Authentication key are not associated with IPv6 OSPF interfaces 🔐
Interface states, events, and the interface state machine are unchanged from IPv4, as documented in Sections 9.1, 9.2, and 9.3 of [OSPFV2] respectively. The Designated Router and Backup Designated Router election algorithm also stays the same as the IPv4 election in Section 9.4 of [OSPFV2] 🗳️
4.1.3. The Neighbor Data Structure
The neighbor structure does the same job in IPv6 and IPv4. Basically, it collects all the info needed to form an adjacency between two routers when one becomes necessary. Each neighbor structure is bound to a single OSPF interface. Here's how the IPv6 neighbor structure differs from the one defined for IPv4 in Section 10 of [OSPFV2]:
Neighbor's Interface ID
- The Interface ID the neighbor advertises in its Hello packets must be recorded in the neighbor structure. The router includes the neighbor's Interface ID in its router-LSA when either a) it's advertising a point-to-point or point-to-multipoint link to the neighbor, or b) it's advertising a link to a network where the neighbor has become the Designated Router 🤝
Neighbor IP address
- This is the neighbor's IPv6 address, found as the source address in OSPF for IPv6 packets. It will be an IPv6 link-local address for all link types except virtual links 📍
Neighbor's Designated Router
- The neighbor's choice of Designated Router is now encoded as a Router ID instead of an IP address 🆗
Neighbor's Backup Designated Router
- The neighbor's choice of Backup Designated Router is now encoded as a Router ID instead of an IP address 🆗
Neighbor states, events, and the neighbor state machine are unchanged from IPv4, as documented in Sections 10.1, 10.2, and 10.3 of [OSPFV2] respectively. The decision about which adjacencies to form also stays the same as the IPv4 logic in Section 10.4 of [OSPFV2] ✅
4.2. Protocol Packet Processing
OSPF for IPv6 runs directly over IPv6's network layer. So it gets encapsulated in one or more IPv6 headers, with the Next Header field of the immediately encapsulating IPv6 header set to the value 89 📦
Same as OSPF for IPv4, OSPF for IPv6 routing protocol packets are only sent along adjacencies (with the exception of Hello packets, which are how the adjacencies get discovered in the first place) 🤙 OSPF packet types and functions are the same in IPv4 and IPv6, encoded by the Type field of the standard OSPF packet header 💖
4.2.1. Sending Protocol Packets ✨
okay so when an IPv6 router sends an OSPF routing protocol packet, it fills in the fields of the standard OSPF for IPv6 packet header (see Appendix A.3.1) like this 💅
Version #: Set to 3, the version number of the protocol as documented in this specification. 🌸Type: the type of OSPF packet, like a 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, aka who is originating the packet 👑Area ID: the OSPF area for the interface the packet is being sent on 🧚Instance ID: the OSPF Instance ID associated with the interface the packet is going out of 💜Checksum: the standard IPv6 Upper-Layer checksum (as described in Section 8.1 of [IPV6]) covering the entire OSPF packet and prepended IPv6 pseudo-header (see Appendix A.3.1). this one is giving very careful 🙈
Picking the source and destination addresses works exactly like the IPv4 logic in Section 8.1 of [OSPFV2] 🎀. The IPv6 destination is chosen from AllSPFRouters, AllDRouters, and the Neighbor IP address on the other end of the adjacency (which in IPv6, for all links except virtual links, is an IPv6 link-local address). ngl that's a lot of addresses, but it's all very on-brand 💅
Sending Link State Request packets and Link State Acknowledgment packets stays the same as the IPv4 procedures in Sections 10.9 and 13.5 of [OSPFV2], respectively. Hello packets are covered in Section 4.2.1.1, Database Description packets are in Section 4.2.1.2, and Link State Update packets are documented in Section 4.5.2. ✨
4.2.1.1. Sending Hello Packets 🦋
okay bestie, IPv6 changes how OSPF Hello packets get sent in a few ways (compare to Section 9.5 of [OSPFV2]):
- Before the Hello packet is sent on an interface, the interface's
Interface IDMUST be copied into the Hello packet. 🪞 - The Hello packet no longer contains an IP network mask, since OSPF for IPv6 runs per-link instead of per-subnet. not me giving minimalist energy 🤍
- The Designated Router and Backup Designated Router are now shown in Hellos by their Router IDs instead of their IP interface addresses. Advertising the Designated Router (or Backup Designated Router) as
0.0.0.0means it hasn't been chosen yet 🌈 - The
Optionsfield in Hello packets has moved around and gotten bigger, so more Options bits are possible now 🔥 Those that MUST be set correctly in Hello packets are these: theE-bitis set if and only if the interface attaches to a regular area, i.e., not a stub or NSSA area. TheN-bitis set if and only if the interface attaches to an NSSA area (see [NSSA]). Finally, theDC-bitis set if and only if the router wants to stop sending future Hellos over the interface (see [DEMAND]). Unrecognized bits in the Hello packet'sOptionsfield should be cleared. 💀
Sending Hello packets on NBMA networks works for IPv6 in exactly the same way as IPv4, as documented in Section 9.5.1 of [OSPFV2]. iconic consistency 👑
4.2.1.2. Sending Database Description Packets 🌸
the sending of Database Description packets is different from Section 10.8 of [OSPFV2] in one main way:
- The
Optionsfield in Database Description packets has moved around and gotten bigger too, so more Options bits are possible now 💅 Those that MUST be set correctly in Database Description packets are these: theDC-bitis set if and only if the router wants to stop sending Hellos over the interface (see [DEMAND]). Unrecognized bits in the Database Description packet'sOptionsfield should be cleared. 🫶
4.2.2. Receiving Protocol Packets 🧚
so whenever a router receives an OSPF protocol packet, the packet gets marked with the interface it came in on. For routers with virtual links configured, it might not be obvious which interface the packet belongs to 🙈. For example, check out Router RT11 in Figure 6 of [OSPFV2]. If RT11 gets an OSPF protocol packet on its interface to Network N8, it might want to link the packet to the interface to Area 2, or to the virtual link to Router RT10 (which is part of the backbone). In what follows, we assume the packet is first associated with the non-virtual link. 🦋
For the packet to 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 associated with the receiving interface (this includes link-local addresses), one of the IPv6 multicast addresses
AllSPFRoutersorAllDRouters, or an IPv6 global address (for virtual links). 🎯 - The
Next Headerfield of the immediately encapsulating IPv6 header MUST specify the OSPF protocol (89). 🔥 - Any encapsulating IP Authentication Headers (see [IPAUTH]) and the IP Encapsulating Security Payloads (see [IPESP]) MUST be processed and/or verified to make sure the OSPF routing exchanges have integrity and authentication/confidentiality. This is described in [OSPFV3-AUTH]. 🔐
After the encapsulating IPv6 headers are processed, the OSPF packet header gets processed. The fields in the header must match the ones configured for the receiving OSPFv3 interface. If they do not, the packet SHOULD be discarded:
- The version number field MUST specify protocol version 3. 🌈
- The IPv6 Upper-Layer checksum (as described in Section 8.1 of [IPV6]), covering the entire OSPF packet and prepended IPv6 pseudo-header, must be verified (see Appendix A.3.1). 🧮
- The Area ID and Instance ID found in the OSPF header must be verified. If both of the following cases fail, the packet should be discarded. The Area ID and Instance ID specified in the header must either:
- Match one of the Area ID(s) and Interface Instance ID(s) for the receiving link. Unlike IPv4, the IPv6 source address is not restricted to lie within the same IPv6 subnet as the receiving link. IPv6 OSPF runs per-link instead of per-IP-subnet. 🌸
- Match the backbone area and other criteria for a configured virtual link. The receiving router must be an ABR (Area Border Router), and the Router ID in the packet (the source router) must be the other end of a configured virtual link. Also, the receiving link must have an OSPFv3 interface that attaches to the virtual link's configured transit area, and the Instance ID must match the virtual link's Instance ID. If all of these checks succeed, the packet is accepted and associated with the virtual link (and the backbone area). 🎀
- Locally originated packets SHOULD NOT be processed by OSPF, except for support of multiple interfaces attached to the same link as described in Section 4.9. Locally originated packets have a source address equal to one of the router's local addresses. 🙅♀️
- Packets whose IPv6 destination is
AllDRoutersshould only be accepted if the state of the receiving OSPFv3 interface is DR or Backup (see Section 9.1 [OSPFV2]). 👑
After header processing, the packet gets handled 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 go through the Hello packet processing described in Section 4.2.2.1. Every other packet type is only sent and received on adjacencies, which means the packet must have come from 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 is almost identical to the IPv4 procedures in Sections 10.6, 10.7, and 13.7 of [OSPFV2], respectively, with the exceptions below. 💖
- LSAs with unknown LS types in Database Description packets that have an acceptable flooding scope are processed the same way as LSAs with known LS types. In OSPFv2 [OSPFV2], these would bring the adjacency down with a
SequenceMismatchevent. main character energy 🌈
Receiving Hello packets is documented in Section 4.2.2.1, and receiving Link State Update packets is documented in Section 4.5.1. ⭐
4.2.2.1. Receiving Hello Packets 🦋
the receive processing of Hello packets is different from Section 10.5 of [OSPFV2] in these 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. 🌷
- There is no longer a
Network Maskfield in the Hello packet. bye bye mask 💅 - The neighbor's choice of Designated Router and Backup Designated Router is now encoded as an OSPF Router ID instead of an IP interface address. 🍓
4.3. The Routing table Structure 🗺️
okay so the routing table OSPF uses for IPv4 is defined in Section 11 of [OSPFV2] 💅 for IPv6 there are analogous routing table entries: there are routing table entries for IPv6 address prefixes and also for AS boundary routers. the latter routing table entries are only used to hold intermediate results during the routing table build process (see Section 4.8) ✨
also, to hold the intermediate results during the shortest-path calculation for each area, there is a separate routing table for each area holding the following entries:
- An entry for each router in the area. routers are identified by their OSPF Router ID 🦋 these routing table entries hold the set of shortest paths through a given area to a given router, which in turn allows calculation of paths to the IPv6 prefixes advertised by that router in intra-area-prefix-LSAs. if the router is also an area border router, these entries are also used to calculate paths for inter-area address prefixes. if in addition the router is the other endpoint of a virtual link, the routing table entry describes the cost and viability of the virtual link 🔥
- An entry for each transit link in the area. transit links have associated network-LSAs. both the transit link and the network-LSA are identified by a combination of the Designated Router's Interface ID on the link and the Designated Router's OSPF Router ID 💜 these routing table entries allow later calculation of paths to IP prefixes advertised for the transit link in intra-area-prefix-LSAs.
the fields in the IPv4 OSPF routing table (see Section 11 of [OSPFV2]) remain valid for IPv6: optional capabilities (routers only), path type, cost, type 2 cost, link state origin, and for each of the equal cost paths to the destination, the next-hop and advertising routers 🌸
for IPv6, the link-state origin field in the routing table entry is the router-LSA or network-LSA that has directly or indirectly produced the routing table entry. for example, if the routing table entry describes a route to an IPv6 prefix, the link state origin is the router-LSA or network-LSA that is listed in the body of the intra-area-prefix-LSA that has produced the route (see Appendix A.4.10) 🧚
4.3.1. Routing Table Lookup
routing table lookup (i.e., determining the best matching routing table entry during IP forwarding) is the same for IPv6 as for IPv4 🫶
4.4. Link State Advertisements
for IPv6, the OSPF LSA header has changed slightly, with the LS type field expanding and the Options field being moved into the body of appropriate LSAs 🌈 also, the formats of some LSAs have changed somewhat (namely, router-LSAs, network-LSAs, AS-external-LSAs, and NSSA-LSAs), while the names of other LSAs have been changed (type 3 and 4 summary-LSAs are now inter-area-prefix-LSAs and inter-area-router-LSAs respectively) and additional LSAs have been added (link-LSAs and intra-area-prefix-LSAs). Type of Service (TOS) has been removed from the OSPFv2 specification [OSPFV2] and is not encoded within OSPF for IPv6's LSAs 💀
these changes will be described in detail in the following subsections ✨
4.4.1. The LSA Header
in both IPv4 and IPv6, all OSPF LSAs begin with a standard 20-byte LSA header 🎀 however, the contents of this 20-byte header have changed in IPv6. the LS age, Advertising Router, LS Sequence Number, LS checksum, and length fields within the LSA header remain unchanged, as documented in Sections 12.1.1, 12.1.5, 12.1.6, 12.1.7, and A.4.1 of [OSPFV2], respectively. however, the following fields have changed for IPv6:
Options— theOptionsfield has been removed from the standard 20-byte LSA header and moved into the body of router-LSAs, network-LSAs, inter-area-router-LSAs, and link-LSAs. the size of theOptionsfield has increased from 8 to 24 bits, and some of the bit definitions have changed (see Appendix A.2). additionally, a separatePrefixOptionsfield, 8 bits in length, is attached to each prefix advertised within the body of an LSA 🙈LS type— the size of theLS typefield has increased from 8 to 16 bits, with high-order bit encoding the handling of unknown types and the next two bits encoding flooding scope. see Appendix A.4.2.1 for the current coding of theLS typefield 🍓Link State ID— theLink State IDremains at 32 bits in length. however, except for network-LSAs and link-LSAs, theLink State IDhas shed any addressing semantics. for example, an IPv6 router originating multiple AS-external-LSAs could start by assigning the first aLink State IDof0.0.0.1, the second aLink State IDof0.0.0.2, and so on. instead of the IPv4 behavior of encoding the network number within the AS-external-LSA'sLink State ID, the IPv6Link State IDsimply serves as a way to differentiate multiple LSAs originated by the same router. 👑 For network-LSAs, theLink State IDis set to the Designated Router's Interface ID on the link. when a router originates a link-LSA for a given link, itsLink State IDis set equal to the router's Interface ID on the link. 🦋
4.4.2. The Link-State Database
in IPv6, as in IPv4, individual LSAs are identified by a combination of their LS type, Link State ID, and Advertising Router fields. given two instances of an LSA, the most recent instance is determined by examining the LSAs' LS sequence number, using LS checksum and LS age as tiebreakers (see Section 13.1 of [OSPFV2]) 🔥
in IPv6, the link-state database is split across three separate data structures. LSAs with AS flooding scope are contained within the top-level OSPF data structure (see Section 4.1) as long as either their LS type is known or their U-bit is 1 (flood even when unrecognized); this includes the AS-external-LSAs. LSAs with area flooding scope are contained within the appropriate area structure (see Section 4.1.1) as long as either their LS type is known or their U-bit is 1 (flood even when unrecognized); this includes router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, NSSA-LSAs, and intra-area-prefix-LSAs. LSAs with an unknown LS type, the U-bit set to 0, and/or link-local flooding scope are contained within the appropriate interface structure (see Section 4.1.2); this includes link-LSAs. 🌈
to look up or install an LSA in the database, you first examine theLS typeand the LSA's context (i.e., the area or link to which the LSA belongs). this information allows you to find the correct database of LSAs where you then search based on the LSA's type,Link State ID, andAdvertising Router. 💖
4.4.3. Originating LSAs ✨
okay so reoriginating an LSA in IPv6 works exactly the way it does in IPv4 🎀 the LSA's LS sequence number gets incremented, its LS age gets set to 0, its LS checksum gets calculated, and then the LSA goes into the link state database and gets flooded out the right interfaces 🦋
the list of events that trigger reorigination for IPv4 lives in Section 12.4 of [OSPFV2] 💅 IPv6 adds these extra ones:
- The state or interface ID of one of the router's interfaces changes 🌸 The router may need to (re)originate or flush its link-LSA and one or more router-LSAs and/or intra-area-prefix-LSAs. If the router is the Designated Router, it may also need to (re)originate and/or flush the network-LSA for that interface 👑
- 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.
- A new prefix is added to an attached link, or a prefix is deleted (both through configuration) 🍓 This makes the router reoriginate its link-LSA for the link or, if it's the only router attached to the link, reoriginate an intra-area-prefix-LSA.
- A new link-LSA is received, and that changes the link's collection of prefixes 💜 If the router is the Designated Router for the link, it originates a new intra-area-prefix-LSA.
- A new link-LSA is received, and that changes the logical OR of LSA options advertised by adjacent routers on the link 🌈 If the router is the Designated Router for the link, it originates a new network-LSA.
the seven required IPv6 LSA types are built step by step in the subsections below 🎀 to show example LSAs, the network map in Figure 15 of [OSPFV2] got a glow-up with IPv6 addressing, and that gives us Figure 1 ✨ the OSPF cost of each interface is shown in Figure 1, the IPv6 prefix assignments to network links are in Table 1, and the OSPF interface IDs and link-local addresses for the router interfaces are in Table 2. Area 1 has a single area address range configured, so everything in Area 1 is covered by one route to 2001:0db8:c001::/48 when you look from outside the area 💖
..........................................
. Area 1.
. + .
. | .
. | 3+---+1 .
. N1 |--|RT1|-----+ .
. | +---+ \ .
. | \ ______ .
. + \/ \ 1+---+
. * N3 *------|RT4|------
. + /\_______/ +---+
. | / | .
. | 3+---+1 / | .
. N2 |--|RT2|-----+ 1| .
. | +---+ +---+ .
. | |RT3|----------------
. + +---+ .
. |2 .
. | .
. +------------+ .
. N4 .
..........................................
Figure 1: Area 1 with IP Addresses Shown Network IPv6 prefix
-----------------------------------
N1 2001:0db8:c001:0200::/56
N2 2001:0db8:c001:0300::/56
N3 2001:0db8:c001:0100::/56
N4 2001:0db8:c001:0400::/56
Table 1: IPv6 Link Prefixes for Sample Network Router Interface Interface ID link-local address
-------------------------------------------------------
RT1 to N1 1 fe80:0001::RT1
to N3 2 fe80:0002::RT1
RT2 to N2 1 fe80:0001::RT2
to N3 2 fe80:0002::RT2
RT3 to N3 1 fe80:0001::RT3
to N4 2 fe80:0002::RT3
RT4 to N3 1 fe80:0001::RT4
Table 2: OSPF Interface IDs and Link-Local Addresses Figure 14.4.3.1. LSA Options 🌟
the Options field in LSAs should be coded like this 💅 the V6-bit should be set unless the router won't take part in transit IPv6 routing. the E-bit should be clear if and only if the attached area is an OSPF stub or OSPF NSSA area. the E-bit should always be set in AS scoped LSAs. the N-bit should be set if and only if the attached area is an OSPF NSSA area. the R-bit should be set unless the router won't take part in any transit routing. the DC-bit should be set if and only if the router can correctly process the DoNotAge bit when it shows up in the LS age field of LSAs (see [DEMAND]). all unrecognized bits in the Options field should be cleared 🫧
the V6-bit and R-bit are only examined in Router-LSAs during the SPF computation 🧠 in other LSA types that carry options, they're set purely for informational purposes 🙈
4.4.3.2. Router-LSAs 🏠
the LS type of a router-LSA is 0x2001 💖 router-LSAs have area flooding scope. A router MAY originate one or more router-LSAs for a given area 🦋 each router-LSA contains an integral number of interface descriptions. Taken together, the router-LSAs the router originates for an area describe the collected states of all the router's interfaces attached to that area 🌈 when multiple router-LSAs are used, they're told apart by their Link State ID fields 🎀
to the left of the Options field, the router capability bits V, E, and B should be set according to Section 12.4.1 of [OSPFV2] ✨
each of the router's interfaces to the area then gets described by tacking "link descriptions" onto the router-LSA 🌸 each link description is 16 bytes long and has five fields: (link) Type, Metric, Interface ID, Neighbor Interface ID, and Neighbor Router ID (see Appendix A.4.3) 🧚 interfaces in the state "Down" or "Loopback" are not described (though looped back interfaces can still contribute prefixes to intra-area-prefix-LSAs), and neither are interfaces without any full adjacencies (except in the case of multiple Standby Interfaces, as described in Section 4.9) 🙈 all other interfaces to the area add zero, one, or more link descriptions, and how many 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 the neighbor advertised in its Hello packets, and the Neighbor Router ID field is set to the neighbor's Router ID.
Broadcast and NBMA interfaces 📡 If the router is fully adjacent to the link's Designated Router, or if the router itself is the Designated Router and is fully adjacent to at least one other router, add a single Type 2 link description (transit network). The Neighbor Interface ID field is set to the Interface ID the Designated Router advertised 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 the neighbor advertised 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 gets calculated during the routing table calculation (see Section 4.7) 🧮
Point-to-Multipoint interfaces 🫧 For each fully adjacent neighbor associated with the interface, add a separate Type 1 link description (point-to-point), with the Neighbor Interface ID field set to the Interface ID the neighbor advertised in its Hello packets and the Neighbor Router ID field set to the neighbor's Router ID 💖
let's look at an example 👀 consider the router-LSA that router RT3 would originate for Area 1 in Figure 1. Only a single interface has to be described, namely the one connecting to the transit network N3 🎯 this assumes RT4 has been elected the 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.0.2.3 ;RT3's Router ID
bit E = 0 ;not an AS boundary router
bit B = 1 ;area border router
Options = (V6-bit|E-bit|R-bit)
Type = 2 ;connects to N3
Metric = 1 ;cost to N3
Interface ID = 1 ;RT3's Interface ID on N3
Neighbor Interface ID = 1 ;RT4's Interface ID on N3
Neighbor Router ID = 192.0.2.4 ; RT4's Router ID RT3's router-LSA for Area 1now here's where it gets fun 🎢 say another router gets added to Network N4. then RT3 has to advertise a second link description for its connection to (the now transit) network N4 🫶 that can happen by reoriginating the router-LSA above, this time with two link descriptions 💅 or, a separate router-LSA can be originated with a separate Link State ID (for example, a Link State ID of 1) to describe the connection to N4 ✨
host routes for stub networks no longer show up in the router-LSA 😭 instead, they're included in intra-area-prefix-LSAs 🩷
4.4.3.3. Network-LSAs ✨
okay so the LS type for a network-LSA is 0x2002 💖 Network-LSAs have area flooding scope. You originate one for every broadcast or NBMA link that has an elected Designated Router and is fully adjacent with at least one other router on that link 🦋 The link's Designated Router is the one who originates it, and it lists every router on the link that it's fully adjacent with. literally the DR is the main character here 👑
IPv6 network-LSAs are originated the same way as in IPv4, as described in Section 12.4.2 of [OSPFV2], with a few plot twists 🌈
- 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 the addressing info the IPv4 network-LSA used to carry has moved into intra-Area-Prefix-LSAs that the link's Designated Router originates 🎀
- The Options field in the network-LSA is set to the logical OR of the Options fields in the link's associated link-LSAs for the fully adjacent neighbors. So the network link shows a capability whenever at least one fully adjacent neighbor on the link asks for that capability to be advertised ✨
As an example, say Router RT4 has been elected the Designated Router of Network N3 in Figure 1. Then this network-LSA gets originated 🧚
; Network-LSA for Network N3
LS age = 0 ;newly (re)originated
LS type = 0x2002 ;network-LSA
Link State ID = 1 ;RT4's Interface ID on N3
Advertising Router = 192.0.2.4 ;RT4's Router ID
Options = (V6-bit|E-bit|R-bit)
Attached Router = 192.0.2.4 ;Router ID
Attached Router = 192.0.2.1 ;Router ID
Attached Router = 192.0.2.2 ;Router ID
Attached Router = 192.0.2.3 ;Router ID
Network-LSA for Network N34.4.3.4. Inter-Area-Prefix-LSAs 🍓
the LS type for an inter-area-prefix-LSA is 0x2003 💜 These also have area flooding scope. In IPv4 they were called type 3 summary-LSAs. Each inter-area-prefix-LSA describes a prefix that's outside the area but still inside the Autonomous System 🌸
The IPv6 procedure for originating inter-area-prefix-LSAs is the same as the IPv4 one in Sections 12.4.3 and 12.4.3.1 of [OSPFV2], with these exceptions 💅
- The Link State ID of an inter-area-prefix-LSA has lost all of its addressing semantics. It just tells apart multiple inter-area-prefix-LSAs that the same router originates.
- The prefix is described by the PrefixLength, PrefixOptions, and Address Prefix fields inside the LSA body. Network Mask is no longer specified.
- The NU-bit in the PrefixOptions field should be clear.
- Link-local addresses MUST never be advertised in inter-area-prefix-LSAs. 🙈 this one is a hard rule, bestie
As an example, here's the inter-area-prefix-LSA that Router RT4 sends into the OSPF backbone area. It condenses all of Area 1's prefixes into the single prefix 2001:0db8:c001::/48 🦋 The cost is set to 4, which is the maximum cost of all the individual component prefixes. The prefix gets padded out to an even number of 32-bit words, so it takes up 64 bits of space instead of 48 🫶
; Inter-area-prefix-LSA for Area 1 addresses
; originated by Router RT4 into the backbone
LS age = 0 ;newly (re)originated
LS type = 0x2003 ;inter-area-prefix-LSA
Advertising Router = 192.0.2.4 ;RT4's ID
Metric = 4 ;maximum to components
PrefixLength = 48
PrefixOptions = 0
Address Prefix = 2001:0db8:c001 ;padded to 64-bits
Inter-area-prefix-LSA for Area 1 addresses originated
by Router
RT4 into the backbone4.4.3.5. Inter-Area-Router-LSAs 🌈
the LS type for an inter-area-router-LSA is 0x2004 🧚 These have area flooding scope, and in IPv4 they were called type 4 summary-LSAs. Each one describes a path to a destination OSPF router (aka an AS Boundary Router (ASBR)) that's outside the area but inside the Autonomous System 👑
The IPv6 procedure for originating inter-area-router-LSAs is the same as the IPv4 one in Section 12.4.3 of [OSPFV2], with these exceptions ✨
- The Link State ID of an inter-area-router-LSA is no longer the destination router's OSPF Router ID. It just tells apart multiple inter-area-router-LSAs that the same router originates. 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 in the destination router's own router-LSA. That way the Options field describes the capabilities the destination router supports 💖
As an example, picture the OSPF Autonomous System from Figure 6 of [OSPFV2]. Router RT4 would originate this 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.0.2.4 ;RT4's ID
Options = (V6-bit|E-bit|R-bit) ;RT7's capabilities
Metric = 14 ;cost to RT7
Destination Router ID = Router RT7's ID
Inter-area-router-LSA for AS boundary router RT7 originated by Router
RT4 into Area 14.4.3.6. AS-External-LSAs 💜
the LS type for an AS-external-LSA is 0x4005 🌸 These have AS flooding scope. Each AS-external-LSA describes a path to a prefix that's external to the Autonomous System 🍓
The IPv6 procedure for originating AS-external-LSAs is the same as the IPv4 one in Section 12.4.4 of [OSPFV2], with these exceptions 💅
- The Link State ID of an AS-external-LSA has lost all of its addressing semantics. 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 is no longer specified.
- The NU-bit in the PrefixOptions field should be clear.
- Link-local addresses can never be advertised in AS-external-LSAs. 🙈
- The forwarding address is present in the AS-external-LSA if and only if the AS-external-LSA's bit F is set.
- The external route tag is present in the AS-external-LSA if and only if the AS-external-LSA's bit T is set.
- The capability for an AS-external-LSA to reference another LSA is supported through the Referenced LS Type field and the optional Referenced Link State ID field. The latter is present if and only if the Referenced LS Type is non-zero. This capability is for future use. The Referenced LS Type should be set to 0, and received non-zero values for this field should be ignored until its use is defined 🫶
As an example, picture the OSPF Autonomous System from Figure 6 of [OSPFV2]. Say RT7 has learned its route to N12 via BGP and wants to advertise a Type 2 metric into the AS. Also say the IPv6 prefix for N12 is 2001:0db8:0a00::/40. RT7 would then originate this AS-external-LSA for the external network N12. Heads up: inside the AS-external-LSA, N12's prefix takes up 64 bits 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 ;LSA type/scope unique identifier
Advertising Router = Router RT7's ID
bit E = 1 ;Type 2 metric
bit F = 0 ;no forwarding address
bit T = 1 ;external route tag included
Metric = 2
PrefixLength = 40
PrefixOptions = 0
Referenced LS Type = 0 ;no Referenced Link State ID
Address Prefix = 2001:0db8:0a00 ;padded to 64-bits
External Route Tag = as per BGP/OSPF interaction
AS-external-LSA for Network N12, originated by Router RT74.4.3.7. NSSA-LSAs ⭐
the LS type for an NSSA-LSA is 0x2007 🦋 These have area flooding scope. Each NSSA-LSA describes a path to a prefix that's external to the Autonomous System, but whose flooding scope is limited to a single NSSA area 🎀
The IPv6 procedure for originating NSSA-LSAs is the same as the IPv4 one in [NSSA], with these exceptions 💖
- The Link State ID of an NSSA-LSA has lost all of its addressing semantics. It just tells apart multiple NSSA-LSAs that the same router originates in the same area.
- The prefix is described by the PrefixLength, PrefixOptions, and Address Prefix fields inside the LSA body. Network Mask is no longer specified.
- The NU-bit in the PrefixOptions field should be clear.
- Link-local addresses can never be advertised in NSSA-LSAs. 🙈
- The forwarding address is present in the NSSA-LSA if and only if the NSSA-LSA's bit F is set.
- The external route tag is present in the NSSA-LSA if and only if the NSSA-LSA's bit T is set.
- The capability for an NSSA-LSA to reference another LSA is supported through the Referenced LS Type field and the optional Referenced Link State ID field. The latter is present if and only if the Referenced LS Type is non-zero. This capability is for future use. The Referenced LS Type should be set to 0, and received non-zero values for this field should be ignored until its use is defined 🌈
An example of an NSSA-LSA would only differ from an AS-external-LSA in that its LS type would be 0x2007 instead of 0x4005 🧚
4.4.3.8. Link-LSAs ✨
okay so the LS type of a link-LSA is 0x0008 🎀 and these have link-local flooding scope, meaning they stay on the link itself 🧚. A router makes a separate link-LSA for each attached link that has two or more routers on it (the originating router counts too) 💅. Link-LSAs SHOULD NOT be originated for virtual links 🙈.
link-LSAs have three jobs, bestie 🫶
- They hand out the router's link-local address to every other router on the link 🌸.
- They tell the other routers on the link which IPv6 prefixes go with that link 🍓.
- They let the router advertise a set of Options bits inside the network-LSA that the Designated Router originates on a broadcast or NBMA link 👑.
here's how you build a link-LSA for a given Link L, step by step 💖
- The Link State ID gets 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 set to reflect the router's capabilities ✨. On multi-access links, the Designated Router will logically OR the link-LSA Options fields for all fully adjacent neighbors in Link L's network-LSA 🔥.
- The router puts its link-local address on Link L into the link-LSA 🌈. The other routers on Link L use this info when they do their next-hop calculations (see Section 4.8.2) 🫶.
- Every IPv6 address prefix configured on Link L gets added to the link-LSA by setting the PrefixLength, PrefixOptions, and Address Prefix fields 🎀.
once the link-LSA is built for a given link, the router installs it into the associated interface data structure and floods it on the link 🦋. every other router on the link receives the link-LSA, but they do NOT flood it onto other links 🙅♀️ (lowercase "not" in the original, so I'm keeping it plain here 💅).
if LinkLSASuppression is configured for the interface and the interface type is not broadcast or NBMA, origination of the link-LSA may be suppressed 🙈. that means the other routers on the link figure out the router's next-hop address some other way instead of the link-LSA (see Section 4.8.2) ✨. check out Appendix C.3 for the details on the LinkLSASuppression interface configuration parameter 📚.
let's look at an example, the link-LSA that RT3 builds for N3 in Figure 1 🧚. say the prefix 2001:0db8:c001:0100::/56 is configured in RT3 for N3 💅. this makes the following link-LSA, which RT3 floods only on N3 🦋. not every router on N3 has to be configured with the prefix 🌸. 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.0.2.3 ;RT3's Router ID
Rtr Priority = 1 ;RT3's N3 Router Priority
Options = (V6-bit|E-bit|R-bit)
Link-local Interface Address = fe80:0001::RT3
# prefixes = 1
PrefixLength = 56
PrefixOptions = 0
Address Prefix = 2001:0db8:c001:0100 ;pad to 64-bits
RT3's link-LSA for N34.4.3.9. Intra-Area-Prefix-LSAs 🌈
the LS type of an intra-area-prefix-LSA is 0x2009 💜, and these have area flooding scope 🫧. an intra-area-prefix-LSA does one of two things 💅. it either links a list of IPv6 address prefixes to a transit network by pointing at a network-LSA, or it links a list of IPv6 address prefixes to a router by pointing at a router-LSA 🎀. a stub link's prefixes are tied to the router it's attached to 🍓.
a router MAY originate multiple intra-area-prefix-LSAs for a given area 🌸. each intra-area-prefix-LSA has a unique Link State ID and holds a whole number of prefix descriptions 🦋.
a link's Designated Router originates one or more intra-area-prefix-LSAs to advertise that link's prefixes across the whole area 👑. for a link L, L's Designated Router builds an intra-area-prefix-LSA like this 💖
- to show that 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 (that's LS type, Link State ID, and Advertising Router) 🔥. so Referenced LS Type becomes
0x2002, Referenced Link State ID becomes the Designated Router's Interface ID on Link L, and Referenced Advertising Router becomes the Designated Router's Router ID 🧚. - every link-LSA tied to 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 and its Link State ID matches the neighbor's interface ID, the prefix list from 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 shouldn't get copied either 🙅♀️. each prefix is described by the PrefixLength, PrefixOptions, and Address Prefix fields 🎀. if multiple prefixes share the same PrefixLength and Address Prefix, they count as duplicates 👯. in that case their PrefixOptions fields should be logically OR'ed together, and just one copy of the duplicate prefix goes into the intra-area-prefix-LSA 🌈. the Metric field for all prefixes is set to 0 🫶.
- the "# prefixes" field gets set to however many prefixes the router copied into the LSA 💅. if needed, the prefix list can be split across multiple intra-area-prefix-LSAs so the LSA size stays small 🍓.
a router builds an intra-area-prefix-LSA to advertise prefixes for its attached stub links, looped-back interfaces, and hosts 🌸. here's how a Router RTX would build its intra-area-prefix-LSA 🦋
- to show the prefixes belong to the Router RTX itself, RTX sets the Referenced LS Type to
0x2001, the Referenced Link State ID to0, and the Referenced Advertising Router to RTX's own Router ID 👑. - Router RTX looks through its list of interfaces to the area 🧚. if an interface is in the state Down, its prefixes are left out 🙅♀️. if the interface got reported in RTX's router-LSA as a Type 2 link description (link to transit network), then the prefixes that would go into the intra-area-prefix-LSA for that link get skipped 💅. still, any prefixes that would normally have the LA-bit set SHOULD be advertised no matter whether the interface is advertised as a transit link ✨. if the interface type is point-to-multipoint or the interface is in the state Loopback, the global scope IPv6 addresses on that interface (if there are any) get copied into the intra-area-prefix-LSA with the PrefixOptions LA-bit set, the PrefixLength set to 128, and the metric set to 0 🔥. otherwise, the global prefixes configured in RTX for the link get copied in by specifying the PrefixLength, PrefixOptions, and Address Prefix fields 🌈. the Metric field for each of these prefixes is set to the interface's output cost 🎀.
- RTX adds the IPv6 prefixes for any directly attached hosts that belong to the area (see Appendix C.7) to the intra-area-prefix-LSA 🫶.
- if RTX has one or more virtual links configured through the area, it includes one of its global scope IPv6 interface addresses in the LSA (if it isn't already there) 💜. it sets the LA-bit in PrefixOptions, the PrefixLength to 128, and the 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 gets set to the number of prefixes the router copied into the LSA 💅. if needed, the prefix list can be spread across multiple intra-area-prefix-LSAs so the LSA size stays small 🍓.
for example, here's the intra-area-prefix-LSA RT4 originates for Network N3 (assuming RT4 is N3's Designated Router), along with the intra-area-prefix-LSA Router RT3 originates into Area 1 for its own prefixes 🦋
; RT4's Intra-area-prefix-LSA for network link N3
LS age = 0 ;newly (re)originated
LS type = 0x2009 ;Intra-area-prefix-LSA
Link State ID = 5 ;LSA type/scope unique identifier
Advertising Router = 192.0.2.4 ;RT4's Router ID
# prefixes = 1
Referenced LS Type = 0x2002 ;network-LSA reference
Referenced Link State ID = 1
Referenced Advertising Router = 192.0.2.4
PrefixLength = 56 ;N3's prefix
PrefixOptions = 0
Metric = 0
Address Prefix = 2001:0db8:c001:0100 ;pad
; RT3's Intra-area-prefix-LSA for its own prefixes
LS age = 0 ;newly (re)originated
LS type = 0x2009 ;Intra-area-prefix-LSA
Link State ID = 177 ;LSA type/scope unique identifier
Advertising Router = 192.0.2.3 ;RT3's Router ID
# prefixes = 1
Referenced LS Type = 0x2001 ;router-LSA reference
Referenced Link State ID = 0
Referenced Advertising Router = 192.0.2.3
PrefixLength = 56 ;N4's prefix
PrefixOptions = 0
Metric = 2 ;N4 interface cost
Address Prefix = 2001:0db8:c001:0400 ;pad
Intra-area-prefix-LSA for Network Link N3when network conditions change, a router might need to move prefixes from one intra-area-prefix-LSA to another 🔄. say the router is the Designated Router for a link but nothing else is attached to it 🧚. then the link's prefixes get advertised in an intra-area-prefix-LSA that refers to the Designated Router's router-LSA 🌸. once more routers show up on the link, a network-LSA gets originated for it, and the link's prefixes move to an intra-area-prefix-LSA that refers to that network-LSA 🎀.
heads up, bestie 🚨: in the intra-area-prefix-LSA, the Referenced Advertising Router is always equal to the router that's originating the intra-area-prefix-LSA (aka the LSA's Advertising Router) 💀. it seems redundant, but it's there because it might not be redundant later 🤔. someday we may want the same LSA format to advertise address prefixes for other protocol suites 🌈. in that case the Designated Router may not be running that other protocol suite, so another of the link's routers may need to originate the intra-area-prefix-LSA 👑. then the Referenced Advertising Router and the Advertising Router would be different 🫶.
4.4.4. Future LSA Validation ✨
okay so bestie, it is expected that NEW LSAs will get defined that won't be processed during the Shortest Path First (SPF) calculation from Section 4.8 🦋 like, OSPFv3 LSAs carrying info that OSPFv2 already sends using opaque LSAs [OPAQUE]. the main rule is that the new info in future LSAs should not be used unless the OSPFv3 router that originated the LSA is reachable 🫶 BUT, depending on the app and what data is advertised, this reachability check MAY be done less often than every SPF calculation ✨
and for inter-area reachability validation, any OSPFv3 router that originates AS scoped LSAs counts as an AS Boundary Router (ASBR) 👑
4.5. Flooding
okay flooding is giving "mostly the same as IPv4" energy 💅 most of the algorithm from Section 13 of [OSPFV2] is unchanged. the big stuff like figuring out which LSA instance is newer (Section 13.1 of [OSPFV2]), responding to updates of self-originated LSAs (Section 13.4 of [OSPFV2]), sending Link State Acknowledgment packets (Section 13.5 of [OSPFV2]), retransmitting LSAs (Section 13.6 of [OSPFV2]), and receiving Link State Acknowledgment packets (Section 13.7 of [OSPFV2]) is EXACTLY the same for IPv6 and IPv4 🌸
BUT (plot twist 😭) adding flooding scope and unknown LSA type handling (see Appendix A.4.2.1) changed some things in the flooding algorithm. receiving Link State Updates (Section 13 in [OSPFV2]) and sending them (Section 13.3 of [OSPFV2]) now has to account for the LSA's scope and U-bit setting. installing LSAs into the database (Section 13.2 of [OSPFV2]) also causes different events in IPv6, because the LSA types got reorganized and the IPv6 LSA contents are different 🎀 we'll go through all of that below 🧚
4.5.1. Receiving Link State Update Packets
the flooding scope being encoded in the LS type, plus needing to process unknown LS types, changes how received Link State Update packets get handled ✨ same as IPv4, every LSA in a received Link State Update packet gets examined. in IPv4 there are eight steps for each LSA, described in Section 13 of [OSPFV2]. for IPv6 all the steps are the same EXCEPT Steps 2 and 3, which are modified like this:
(2) Examine the LSA's LS type. Discard the LSA and get
the next one from the Link State Update packet if the
interface area has been configured as a stub or
NSSA area and the LS type indicates "AS flooding scope".
This generalizes the IPv4 behavior where AS-external-LSAs
and AS-scoped opaque LSAs [OPAQUE] are not flooded
throughout stub or NSSA areas.
(3) Else if the flooding scope in the LSA's LS type is set to
"reserved", discard the LSA and get the next one from
the Link State Update packet.Steps 5b (sending Link State Update packets) and 5d (installing LSAs in the link-state database) in Section 13 of [OSPFV2] are also a bit different for IPv6 🌈 see Sections 4.5.2 and 4.5.3 below for those 💜
4.5.2. Sending Link State Update Packets
sending Link State Update packets is described in Section 13.3 of [OSPFV2] 🍓 for IPv4 and IPv6 the steps are the same (steps 1 through 5 of Section 13.3 in [OSPFV2]), but the list of eligible interfaces to flood the LSA on is different 😭 for IPv6, the eligible interfaces get picked based on these factors:
- The LSA's flooding scope.
- For LSAs with area or link-local flooding scope, the particular area or interface 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 set to 1, unrecognized LS types are stored and flooded as if they were recognized.
picking the eligible interfaces then splits into these cases 🫶
Case 1
the LSA's LS type is recognized 🔥 the eligible interfaces get set based 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 on interfaces connecting to stub or NSSA areas. if the flooding scope is "area flooding scope", the eligible interfaces are the ones connecting to the LSA's associated area. if the flooding scope is "link-local flooding scope", there's just ONE eligible interface: the one connecting to the LSA's associated link (which is also the interface the LSA was received on in a Link State Update packet) 💖
Case 2
the LS type is unrecognized AND the U-bit in the LS type is set to 0 (treat the LSA as if it had link-local flooding scope) 🙈 in this case there's a single eligible interface, namely the interface the LSA was received on ✨
Case 3
the LS type is unrecognized, and the U-bit in the LS type is set to 1 (store and flood the LSA as if the type is understood) 🧚 in this case, pick the eligible interfaces based on the encoded flooding scope, the same as in Case 1 above 🌸
sometimes one more decision has to be made before adding an LSA to a given neighbor's link-state retransmission list (Step 1d in Section 13.3 of [OSPFV2]) 💅 if the LS type is recognized by the router but NOT by the neighbor (you can tell by checking the Options field that the neighbor advertised in its Database Description packet), AND the LSA's U-bit is set to 0, then the LSA should be added to the neighbor's link-state retransmission list if and only if that neighbor is the Designated Router or Backup Designated Router for the attached link 🎀
the LS types described in detail by this document are router-LSAs (LS type 0x2001), network-LSAs (0x2002), inter-area-prefix-LSAs (0x2003), inter-area-router-LSAs (0x2004), NSSA-LSAs (0x2007), AS-external-LSAs (0x4005), link-LSAs (0x0008), and Intra-Area-Prefix-LSAs (0x2009). these are assumed to be understood by all routers 🌈 HOWEVER, all LS types MAY not be understood by all routers 👑 for example, a new LSA type with its U-bit set to 0 MAY only be understood by a subset of routers 🦋 that new LS type should only be flooded to an OSPF neighbor that understands the LS type, or when the neighbor is the Designated Router or Backup Designated Router for the attached link 💜
the previous paragraph fixes a problem for IPv4 OSPF extensions, which need the Designated Router to support the extension before the new LSA types can be flooded across broadcast and NBMA networks 🍓
4.5.3. Installing LSAs in the Database
there are three separate places to store LSAs, depending on their flooding scope 🧚 LSAs with AS flooding scope are stored in the global OSPF data structure (see Section 4.1) as long as their LS type is known OR their U-bit is 1 ✨ LSAs with area flooding scope are stored in the appropriate area data structure (see Section 4.1.1) as long as their LS type is known OR their U-bit is 1 🌸 LSAs with link-local flooding scope, AND those with an unknown LS type and U-bit set to 0 (treat the LSA as if it had link-local flooding scope), are stored in the appropriate interface data structure 🫶
when storing the LSA into the link-state database, you have to check whether the LSA's contents changed 👀 changes in contents are indicated exactly as in Section 13.2 of [OSPFV2]. when an LSA's contents have changed, these parts of the routing table have to be recalculated, based on the LSA's LS type 💅
Router-LSAs, Network-LSAs, Intra-Area-Prefix-LSAs, and Link-LSAs
the entire routing table gets recalculated, starting with the shortest-path calculation for each area (see Section 4.8) 🔥
Inter-Area-Prefix-LSAs and Inter-Area-Router-LSAs
the best route to the destination described by the LSA has to be recalculated (see Section 16.5 in [OSPFV2]). if this destination is an AS boundary router, it may also be necessary to re-examine all the AS-external-LSAs 🎀
AS-external-LSAs and NSSA-LSAs
the best route to the destination described by the AS-external-LSA or NSSA-LSA has to be recalculated (see Section 16.6 in [OSPFV2] and Section 2.0 in [NSSA]) 🌈
as in IPv4, any old instance of the LSA must be removed from the database when the new LSA is installed 💖 that old instance also has to be removed from all neighbors' link-state retransmission lists 🙈
4.6. Definition of Self-Originated LSAs
in IPv6 the definition of a self-originated LSA got simplified compared to the IPv4 one in Sections 13.4 and 14.1 of [OSPFV2] ✨ for IPv6, self-originated LSAs are the ones whose Advertising Router is equal to the router's own Router ID 🦋
4.7. Virtual Links
OSPF virtual links for IPv4 are described in Section 15 of [OSPFV2] 🌸 virtual links are the same in IPv6, with these exceptions:
- LSAs with AS flooding scope are NEVER flooded over virtual adjacencies, and LSAs with AS flooding scope are not summarized over virtual adjacencies during the database exchange process either 😭 this generalizes the IPv4 treatment of AS-external-LSAs 💅
- The IPv6 interface address of a virtual link MUST be an IPv6 address having global scope, instead of the link-local addresses used by other interface types 🔥 this address is used as the IPv6 source for OSPF protocol packets sent over the virtual link 🫶 so a link-LSA SHOULD NOT be originated for a virtual link, since the virtual link has no link-local address or associated prefixes 🙈
- the virtual neighbor's IPv6 address is an IPv6 address with global scope too 🎀 to let you 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 Section 4.4.3.9 and Section 4.8.1) 🧚
- like all other IPv6 OSPF interfaces, virtual links get assigned unique (within the router) Interface IDs 🌈 these are advertised in Hellos sent over the virtual link AND in the router's router-LSAs 💜
4.8. Routing Table Calculation 🧮✨
okay bestie, the IPv6 OSPF routing calculation is giving déjà vu 👀 It goes along the same lines as the IPv4 one and follows the five steps from Section 16 of [OSPFV2]. The big differences are the tea ☕:
- Prefix information has been removed from router-LSAs and network-LSAs and is now advertised in intra-area-prefix-LSAs. Whenever [OSPFV2] says stub networks within router-LSAs should be examined, IPv6 will instead examine prefixes within intra-area-prefix-LSAs. 💅
- 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 and is now only found within the body of LSAs. 🙈
- In IPv6, a router can originate multiple router-LSAs, distinguished by Link State ID, within a single area. These router-LSAs MUST be treated as a single aggregate by the area's shortest-path calculation (see Section 4.8.1). 👑
For each area, the shortest-path tree calculation creates routing table entries for the area's routers and transit links (see Section 4.8.1). Those entries are then used when processing intra-area-prefix-LSAs, inter-area-prefix-LSAs, and inter-area-router-LSAs, as described in Section 4.8.3. It's giving main character energy 🦋
Events generated as a result of routing table changes (Section 16.7 of [OSPFV2]) and the equal-cost multipath logic (Section 16.8 of [OSPFV2]) are identical for both IPv4 and IPv6. no notes 🫶
4.8.1. Calculating the Shortest-Path Tree for an Area 🌳
The IPv4 shortest-path calculation lives in Section 16.1 of [OSPFV2]. The graph used by the shortest-path tree calculation is identical for both IPv4 and IPv6. 🤝 The graph's vertices are routers and transit links, represented by router-LSAs and network-LSAs respectively. A router is identified by its OSPF Router ID, while a transit link is identified by its Designated Router's Interface ID and OSPF Router ID. Both routers and transit links have associated routing table entries within the area (see Section 4.3).
Section 16.1 of [OSPFV2] splits the shortest-path calculations into two stages. First, the Dijkstra calculation is performed, and then the stub links are added onto the tree as leaves. IPv6 keeps this split too 🍰
The Dijkstra calculation for IPv6 is identical to the one specified for IPv4, with the following exceptions (referencing the steps from the Dijkstra calculation as described in Section 16.1 of [OSPFV2]):
- 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 the Advertising Router set to V's OSPF Router ID MUST be processed as an aggregate, treating them as fragments of a single large router-LSA. The
Optionsfield and the router type bits (bitsNt,V,E, andB) should always be taken from the router-LSA 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 and the router-LSA
V6-bitorR-bitis not set in the LSA options, the transit link W is ignored and V's next link is examined. 🚫 - In Step 2b, if W is a router, there may again be multiple LSAs associated with the router. All router-LSAs with the Advertising Router set to W's OSPF Router ID MUST be processed as an aggregate, treating them as fragments of a single large router-LSA. 🔁
- In Step 4, there are now per-area routing table entries for each of an area's routers rather than just the area border routers. These entries subsume all the functionality of IPv4's area border router routing table entries, including the maintenance of virtual links. When the router added to the area routing table in this step is the other end of a virtual link, the virtual neighbor's IP address is set as follows: The collection of intra-area-prefix-LSAs originated by the virtual neighbor is examined, with the virtual neighbor's IP address being set to the first prefix encountered with the
LA-bitset. 🌐 - Routing table entries for transit networks, which are no longer associated with IP networks, are also calculated in Step 4 and added to the per-area routing table. 🛣️
The next stage of the shortest-path calculation proceeds similarly to the two steps of the second stage of Section 16.1 in [OSPFV2]. However, instead of examining the stub links within router-LSAs, the list of the area's intra-area-prefix-LSAs is examined. A prefix advertisement whose NU-bit is set SHOULD NOT be included in the routing calculation. 🙅 The cost of any advertised prefix is the sum of the prefix's advertised metric plus the cost to the transit vertex (either router or transit network) identified by intra-area-prefix-LSA's Referenced LS Type, Referenced Link State ID, and Referenced Advertising Router fields. This latter cost is stored in the transit vertex's routing table entry for the area. 🧮
This specification does not require that the above algorithm be used to calculate the intra-area shortest-path tree. However, if another algorithm or optimization is used, an identical shortest-path tree must be produced. It is also important that any alternate algorithm or optimization maintain the requirement that transit vertices must be bidirectional for inclusion in the tree. Alternate algorithms and optimizations are beyond the scope of this specification. 🔍
4.8.2. The Next-Hop Calculation 📍
In IPv6, the calculation of the next-hop's IPv6 address (which will be a link-local address) proceeds along the same lines as the IPv4 next-hop calculation (see Section 16.1.1 of [OSPFV2]). However, there are some differences. 👀 When calculating the next-hop IPv6 address for a router (call it Router X) that shares a link with the calculating router, the calculating router assigns the next-hop IPv6 address to be the link-local interface address contained in Router X's link-LSA (see Appendix A.4.9) for the link. This procedure is necessary for some link types, for example NBMA, where the two routers need not be neighbors and might not be exchanging OSPF Hello packets. For other link types, the next-hop address may be determined via the IPv6 source address in the neighbor's Hello packet. 📬
Additionally, when calculating routes for the area's intra-area-prefix-LSAs, the parent vertex can be either a router-LSA or network-LSA. This is in contrast to the second stage of the OSPFv2 intra-area SPF (Section 16.1 in [OSPFV2]), where the parent vertex is always a router-LSA. In the case where the intra-area-prefix-LSA's referenced LSA is a directly connected network-LSA, the prefixes are also considered to be directly connected. In this case, the next hop is solely the outgoing link and no IPv6 next-hop address is selected. 🎯
4.8.3. Calculating the Inter-Area Routes 🗺️
Calculation of inter-area routes for IPv6 proceeds along the same lines as the IPv4 calculation in Section 16.2 of [OSPFV2], with the following modifications:
- 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 an advertised AS boundary router's OSPF Router ID is carried in the body of an inter-area-router-LSA. 📦
- Prefixes having the NU-bit set in their
PrefixOptionsfield 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 [OSPFV2] can be performed instead of recalculating the entire routing table. ⚡
4.8.4. Examining Transit Areas' Summary-LSAs 🚌
Examination of transit areas' summary-LSAs in IPv6 proceeds along the same lines as the IPv4 calculation in Section 16.3 of [OSPFV2], modified in the same way as the IPv6 inter-area route calculation in Section 4.8.3. 🔁
4.8.5. Calculating AS External and NSSA Routes 🌍
The IPv6 AS external route calculation proceeds along the same lines as the IPv4 calculation in Section 16.4 of [OSPFV2] and Section 2.5 of [NSSA], with the following exceptions:
- The Link State ID of the AS-external-LSA and NSSA-LSA types no longer encodes the network described by the LSA. Instead, an address prefix is contained in the body of the LSA. 📦
- The default route in AS-external-LSAs or NSSA-LSAs is advertised by a zero-length prefix. 0️⃣
- Instead of comparing the AS-external-LSA's or NSSA-LSA's
Forwarding Addressfield to0.0.0.0to see whether a forwarding address has been used, the bitFin the respective LSA is examined. A forwarding address is in use if and only if bitFis set. 🚩 - Prefixes having the NU-bit set in their
PrefixOptionsfield should be ignored by the inter-area route calculation. 🙈 - AS Boundary Router (ASBR) and forwarding address selection will proceed the same as if
RFC1583Compatibilityis disabled. Furthermore,RFC1583Compatibilityis not an OSPF for IPv6 configuration parameter. Refer to Appendix C.1. 💅
Quick reminder: RFC1583Compatibility isn't a thing in OSPF for IPv6, so don't go looking for it in your config 🙃
When a single AS-external-LSA or NSSA-LSA has changed, the incremental calculations outlined in Section 16.6 of [OSPFV2] can be performed instead of recalculating the entire routing table. that's the whole routing calc, periodt 🌈✨
4.9. Multiple Interfaces to a Single Link ✨
okay so in OSPF for IPv6, a router can have multiple interfaces to one link, all tied to the same OSPF instance and area. 🦋 All of those interfaces handle data traffic, but only ONE of them sends and receives OSPF control traffic. Here's how it all works, bestie 💅
- Each of the interfaces gets its own Interface ID. The router automatically notices that several interfaces share a link when it gets a Hello packet whose source is one of its own link-local addresses and whose Interface ID is different from the one on the interface that received it. 🔍
- Every interface MUST be configured with the same Interface Instance ID to count as being on the same link. If an interface has more than one Instance ID, it gets grouped with other interfaces based on whichever IDs match. Each Instance ID gets treated on its own when it comes to grouping interfaces on a link. For example, say interface A has Instance IDs 1 and 35, and interface B has Instance ID 35. Then interface B might be the Active Interface for Instance ID 35, while interface A stays active for Instance ID 1. 🎀
- The router ignores OSPF packets other than Hello packets on all but one of the interfaces attached to the link. It only sends its OSPF control packets (Hello packets included) out of one interface. That one is the Active Interface, and the others on the same link are the Standby Interfaces. 👑 Which interface becomes Active is up to the implementation. For example, it could pick the interface with the highest Interface ID. If the router gets elected Designated Router, the Active Interface's Interface ID is what gets used as the network-LSA's Link State ID.
- All of the interfaces to the link (Active and Standby) show up in the router-LSA. On top of that, a link-LSA gets generated for each interface. So every interface gets counted in OSPF's routing calculations. 🧚
- Any link-local scope LSAs originated for a Standby Interface get flooded over the Active Interface. If a Standby Interface goes down, the link-local scope LSAs originated for it MUST be flushed on the Active Interface. 🧹
- Prefixes on Standby Interfaces get handled the exact same way as prefixes on the Active Interface. For example, if the router is the DR for the link, the Active Interface's prefixes go into an intra-area-prefix-LSA tied to the Active Interface's network-LSA, and prefixes from the Standby Interfaces on that link get added to that same intra-area-prefix-LSA. Likewise, if the link is a stub link, the prefixes for the Active and Standby Interfaces all go into the same intra-area-prefix-LSA tied to the router-LSA. 🌸
- If the Active Interface fails, a new Active Interface has to take over. The new Active Interface SHOULD form all new neighbor adjacencies with routers on the link. The failure can get noticed when the router's other interfaces to the Active Interface's link stop hearing its Hellos, or through internal mechanisms, like monitoring the Active Interface's status. 🙈
- If the network gets partitioned, with different local interfaces attached to different partitions, then several interfaces become Active Interfaces and work independently. 💜
- During the SPF calculation, when a network-LSA for a network directly connected to the root vertex is being examined, all of the multiple interfaces to the link of adjacent router-LSAs must be used in the next-hop calculation. You can do this during the back link check (see Section 16.1, Step 2 (B), in [OSPFV2]) by going through each link of the router-LSA and making a list of the links that point to the network-LSA. Then the Interface IDs for the links on that list get used to find the matching link-LSAs, and the link-local addresses from those become the next hops when installing equal-cost paths in the routing table. 🔥
- The interface state machine gets a new state called Standby. See Section 4.9.1 for the full scoop on the Standby state. 🍓
4.9.1. Standby Interface State 💖
okay so in this state, the interface is one of several interfaces to a link. It's designated Standby, and it is NOT sending or receiving control packets. 🙅♀️ It keeps listening for the Hello packets the Active Interface sends. It also runs a timer called the Active Interface Timer, which uses the same interval as the RouterDeadInterval. Every time a Hello packet comes in from the Active Interface on the link, that timer gets reset. ⏱️
Two new events are added to the list of events that can change interface state: MultipleInterfacesToLink and ActiveInterfaceDead. Here's the tea on each one:
MultipleInterfacesToLink An interface on the router has received a Hello packet from another interface on the same router. One of the interfaces gets designated as the Active Interface and the other gets designated as a Standby Interface. The Standby Interface transitions to the Standby state. ✨
ActiveInterfaceDead There's been an indication that a Standby Interface is no longer on a link with an Active Interface. The Active Interface Timer firing is one indication of this event, since it means the Standby Interface hasn't gotten an OSPF Hello packet from the Active Interface for the RouterDeadInterval. Other indications can come from internal notifications, like the Active Interface being disabled through a configuration change. Any indication inside the router that tells it the Active Interface is no longer active on the link can trigger the ActiveInterfaceDead event for a Standby Interface. 😭
The interface state machine additions look like this:
State(s): Waiting, DR Other, Backup, or DR
Event: MultipleInterfacesToLink
New state: Standby
Action: All interface variables are reset and interface
timers disabled. Also, all neighbor connections
associated with the interface are destroyed. This
is done by generating the event KillNbr on all
associated neighbors. The Active Interface Timer is
started and the interface will listen for OSPF Hello
packets from the link's Active Interface.
State(s): Standby
Event: ActiveInterfaceDead
New state: Down
Action: The Active Interface Timer is first disabled. Then
the InterfaceUp event is invoked.
Standby Interface State Machine Additions5. Security Considerations 🔐
bestie, this part is serious, so read it slowly 🫶 When it runs over IPv6, OSPFv3 relies on the IP Authentication Header (see [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) to make sure protocol packets have integrity and authentication/confidentiality. All of that is described in [OSPFV3-AUTH].
Most OSPFv3 implementations will be running on systems that support multiple protocols, each with their own independent security assumptions and domains. When IPsec is used to protect OSPFv3 packets, the implementation has to check the IPsec Security Association (SA) and the local SA database. That makes sure the OSPF packet came from a source that's trusted for OSPFv3. This is required so that a packet can't have been authenticated using an SA defined for some other protocol running on the same system. 🚨
The mechanisms in [OSPFV3-AUTH] do NOT protect against compromised, malfunctioning, or misconfigured routers. Routers like that can, by accident or on purpose, cause malfunctions that hit the whole routing domain. 😱 If you want the full picture on threats to routing protocols, the reader is encouraged to check out [GENERIC-THREATS].
6. Manageability Considerations 🛠️
The Management Information Base (MIB) for OSPFv3 is defined in [OSPFV3-MIB]. 📚
7. IANA Considerations 🧾
Most OSPF for IPv6 IANA considerations are documented in [OSPF-IANA]. IANA has updated the reference for RFC 2740 to this document. 💅
Also, this document adds the following IANA requirements that weren't in [OSPFV3]:
- Reserves the options with the values 0x000040 and 0x000080 for migrated OSPFv2 options in the OSPFv3 Options registry defined in [OSPF-IANA]. For info on the OSPFv3 Options field, check Appendix A.2.
- Adds the prefix option P-bit with value 0x08 to the OSPFv3 Prefix Options registry defined in [OSPF-IANA]. For info on OSPFv3 Prefix Options, check Appendix A.4.1.1.
- Adds the prefix option DN-bit with value 0x10 to the OSPFv3 Prefix Options registry defined in [OSPF-IANA]. For info on OSPFv3 Prefix Options, check Appendix A.4.1.1.
7.1. MOSPF for OSPFv3 Deprecation IANA Considerations 🌈
With MOSPF for OSPFv3 getting deprecated, these code points are up for grabs for reassignment. Check [OSPF-IANA] for the respective registries. This document:
- Deprecates the MC-bit with value 0x000004 in the OSPFv3 Options registry.
- Deprecates Group-membership-LSA with value 6 in OSPFv3 LSA Function Code registry.
- Deprecates MC-bit with value 0x04 in the OSPFv3 Prefix Options registry.
The W-bit in the OSPFv3 Router Properties has also been deprecated. That means there needs to be a new registry for OSPFv3 router properties, since it's going to diverge from the OSPFv2 Router Properties. 🦋
Registry Name: OSPFv3 Router Properties Registry
Reference: RFC 5340
Registration Procedures: Standards Action
Registry:
Value Description Reference
------ ------------- ---------
0x01 B-bit RFC 5340
0x02 E-bit RFC 5340
0x04 V-bit RFC 5340
0x08 Deprecated RFC 5340
0x10 Nt-bit RFC 5340
OSPFv3 Router Properties Registry8. Acknowledgments 🫶
okay bestie, this is the thank-you section and it's giving main character energy for everyone who helped 🥹 The RFC text was produced using Marshall Rose's xml2rfc tool 🛠️ ✨
The following people contributed comments that got folded into this document:
- Harold Rabbie for his description of protocol details that needed to be clarified for OSPFv3 NSSA support 🙌
- Nic Neate for pointing out that there needed to be changes for unknown LSA types handling in the processing of Database Description packets 🔍
- Jacek Kwiatkowski for being the first to point out that the V6- and R-bits are not taken into account in the OSPFv3 intra-area SPF calculation 🧠
- Michael Barnes recognized that the support for multiple interfaces to a single link was broken (see Section 4.9) and provided the description of the current protocol mechanisms 💅 Abhay Roy reviewed and suggested improvements to the mechanisms 🌸
- Alan Davey reviewed and commented on document revisions ✨
- Vivek Dubey reviewed and commented on document revisions 🦋
- Manoj Goyal and Vivek Dubey complained enough about link-LSAs being unnecessary to compel introduction of the LinkLSASuppression interface configuration parameter 😭 iconic pushback
- Manoj Goyal for pointing out that the next-hop calculation for intra-area-prefix-LSAs corresponding to network vertices was unclear 👀
- Ramana Koppula reviewed and commented on document revisions 🎀
- Paul Wells reviewed and commented on document revisions 🍓
- Amir Khan reviewed and commented on document revisions 🧚
- Dow Street and Wayne Wheeler commented on the addition of the DN-bit to OSPFv3 💜
- Mitchell Erblichs provided numerous editorial comments 📝
- Russ White provided numerous editorial comments 📝
- Kashima Hiroaki provided editorial comments ✍️
- Sina Mirtorabi suggested that OSPFv3 should be aligned with OSPFv2 with respect to precedence and should map it to IPv6 traffic class as specified in RFC 2474 🌈 Steve Blake helped with the text 💖
- Faraz Shamin reviewed a late version of the document and provided editorial comments 🫶
- Christian Vogt performed the General Area Review Team (Gen-ART) review and provided comments 🔥
- Dave Ward, Dan Romascanu, Tim Polk, Ron Bonica, Pasi Eronen, and Lars Eggert provided comments during the IESG review. Also, thanks to Pasi for the text in Section 5 relating to routing threats 👑 Pasi really carried on that one 🙏
9. References 📚
9.1. Normative References
- [DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
- [DIFF-SERV] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
- [DN-BIT] Rosen, E., Peter, P., and P. Pillay-Esnault, "Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4576, June 2006.
- [INTFMIB] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
- [IP6ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
- [IPAUTH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
- [IPESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
- [IPV4] Postal, J., "Internet Protocol", STD 5, RFC 791, September 1981.
- [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
- [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, January 2003.
- [OSPF-IANA] Kompella, K. and B. Fenner, "IANA Considerations for OSPF", BCP 130, RFC 4940, July 2007.
- [OSPFV2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
- [OSPFV3-AUTH] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
- [RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
- [GENERIC-THREATS] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
- [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
- [MTUDISC] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
- [OPAQUE] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998.
- [OSPFV3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
- [OSPFV3-MIB] Joyal, D. and V. Manral, "Management Information Base for OSPFv3", Work in Progress, September 2007.
- [SERV-CLASS] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006.
Appendix A. OSPF Data Formats 🧾
okay so this appendix is where the actual packet and LSA formats live, and it's giving a whole vibe 🤌 OSPF runs directly over the IPv6 network layer 🌐 Before any data formats get described, we explain the details of the OSPF encapsulation first 💅
Next, we describe the OSPF Options field 🎀 This field describes various capabilities that may or may not be supported by pieces of the OSPF routing domain. The OSPF Options field is contained in OSPF Hello packets, Database Description packets, and OSPF LSAs ✨
OSPF packet formats are detailed in Section A.3 📦
A description of OSPF LSAs appears in Section A.4 🧩 This section describes how IPv6 address prefixes are represented within LSAs, details the standard LSA header, and then provides formats for each of the specific LSA types 🫶
A.1. Encapsulation of OSPF Packets 🎁
OSPF runs directly over the IPv6's network layer 🌈 OSPF packets are therefore encapsulated solely by IPv6 and local data-link headers 💖
OSPF does not define a way to fragment its protocol packets, and depends on IPv6 fragmentation when transmitting packets larger than the link MTU 😬 If necessary, the length of OSPF packets can be up to 65,535 bytes. The OSPF packet types that are likely to be large (Database Description, Link State Request, Link State Update, and Link State Acknowledgment packets) can usually be split into multiple protocol packets without loss of functionality. This is recommended; IPv6 fragmentation should be avoided whenever possible 🍓 Using this reasoning, an attempt should be made to limit the size of OSPF packets sent over virtual links to 1280 bytes unless Path MTU Discovery is being performed [MTUDISC] 🧚
The other important features of OSPF's IPv6 encapsulation are:
- Use of IPv6 multicast. Some OSPF messages are multicast when sent over broadcast networks 📡 Two distinct IP multicast addresses are used. Packets sent to these multicast addresses should never be forwarded; they are meant to travel a single hop only 🦋 As such, the multicast addresses have been chosen with link-local scope and packets sent to these addresses should have their IPv6 Hop Limit set to 1. b
- 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 🔥
- The OSPFv2 specification (Appendix A.1 in [OSPFV2]) indicates that OSPF protocol packets are sent with IP precedence set to Internetwork Control (B'110') [IPV4]. If routers in the OSPF routing domain map their IPv6 Traffic Class octet to the Differentiated Services Code Point (DSCP) as specified in [DIFF-SERV], then OSPFv3 packets SHOULD be sent with their DSCP set to CS6 (B'110000'), as specified in [SERV-CLASS]. In networks supporting this mapping, OSPF packets will be given precedence over IPv6 data traffic 🌟 slay
A.2. The Options Field 🎀
okay so 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's basically how routers say "this is what I can do" ✨ It lets routers support optional capabilities (or not), and tell each other their capability level, so routers with different abilities can live together in one OSPF routing domain 🫶
an option mismatch between routers can cause all kinds of drama 😭 depending on the option, some mismatches stop neighbor relationships from forming (like the E-bit, below), and those get caught when Hello packets are sent and received. some stop particular LSA types from being flooded across adjacencies, and those show up during Database Description packets. and some stop routers from being part of certain routing calculations because they're running with reduced functionality, and those get spotted by looking at the LSAs 👀
seven bits of the Options field have been assigned, and each one gets a quick explanation below 🌈 routers should reset (clear) unrecognized bits when they send Hello packets, Database Description packets, or originate LSAs. and if a router gets unrecognized Options bits in received Hello packets, Database Description packets, or LSAs, it should ignore those bits and just process the packet or LSA normally 🍓
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+
| | | | | | | | | | | | | | | | |*|*|DC|R|N|x| E|V6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+
The Options field
The Options fieldV6-bit 💜 If this bit is clear, the router/link should be excluded from IPv6 routing calculations. See Section 4.8 for details.
E-bit 🦋 This bit describes the way AS-external-LSAs are flooded, as described in Sections 3.6, 9.5, 10.8, and 12.1.2 of [OSPFV2].
x-Bit 🧚 This bit was previously used by MOSPF (see [MOSPF]), which has been deprecated for OSPFv3. The bit should be set to 0 and ignored when received. It may be reassigned in the future.
N-bit 🌸 This bit indicates whether or not the router is attached to an NSSA as specified in [NSSA].
R-bit 👑 This bit (the `Router' bit) indicates whether the originator is an active router. If the router bit is clear, then routes that transit the advertising node cannot be computed. Clearing the router bit would be appropriate for a multi-homed host that wants to participate in routing, but does not want to forward non-locally addressed packets. 🙈
DC-bit 💅 This bit describes the router's handling of demand circuits, as specified in [DEMAND].
*-bit ✨ These bits are reserved for migration of OSPFv2 protocol extensions.
A.3. OSPF Packet Formats 🦋
okay so there are five distinct OSPF packet types, and they ALL start with a standard 16-byte header 💖 that header gets described first, then each packet type gets its own section where you can see its format and what each field means 🫶
all OSPF packet types except the Hello packets deal with lists of LSAs. like, Link State Update packets are the ones doing the flooding of LSAs across the whole OSPF routing domain 🌈 the LSA format is in Section A.4.
the receive processing of OSPF packets is in Section 4.2.2, and the sending side is explained in Section 4.2.1 ✨
A.3.1. The OSPF Packet Header 🎀
every OSPF packet starts with that standard 16-byte header 💅 together with the encapsulating IPv6 headers, the OSPF header has everything needed to decide whether the packet should be accepted for further processing. that decision is described in Section 4.2.2 🍓
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OSPF Packet HeaderVersion # 💜 The OSPF version number. This specification documents version 3 of the OSPF protocol.
Type 🌸 The OSPF packet types are as follows. See Appendix A.3.2 through Appendix A.3.6 for details.
Type Description
---------------------------------
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State AcknowledgmentPacket length 🍓 The length of the OSPF protocol packet in bytes. This length includes the standard OSPF header.
Router ID 👑 The Router ID of the packet's source.
Area ID 🧚 A 32-bit number identifying the area to which this packet belongs. All OSPF packets are associated with a single area. Most travel a single hop only. Packets traversing a virtual link are labeled with the backbone Area ID of 0.
Checksum 🔥 OSPF uses the standard checksum calculation for IPv6 applications: The 16-bit one's complement of the one's complement sum of the entire contents of the packet, starting with the OSPF packet header, and prepending a "pseudo-header" of IPv6 header fields, as specified in Section 8.1 of [IPV6]. The "Upper-Layer Packet Length" in the pseudo-header is set to the value of the OSPF packet header's length field. The Next Header value used in the pseudo-header is 89. If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before checksumming. Before computing the checksum, the checksum field in the OSPF packet header is set to 0. 🧮
Instance ID 🌈 Enables multiple instances of OSPF to be run over a single link. Each protocol instance would be assigned a separate Instance ID; the Instance ID has link-local significance only. Received packets whose Instance ID is not equal to the receiving interface's Instance ID are discarded. 🚫
0 ✨ These fields are reserved. They SHOULD be set to 0 when sending protocol packets and MUST be ignored when receiving protocol packets. 💀
A.3.2. The Hello Packet 🌷
Hello packets are OSPF packet type 1. These packets are sent periodically on all interfaces (including virtual links) in order to establish and maintain neighbor relationships. In addition, Hello packets are multicast on those links having a multicast or broadcast capability, enabling dynamic discovery of neighboring routers. 📡
all routers on a common link must agree on certain parameters (HelloInterval and RouterDeadInterval) 🤝 these parameters are included in Hello packets, so differences can stop neighbor relationships from forming. the Hello packet also carries the fields used for Designated Router election (Designated Router ID and Backup Designated Router ID), and the fields used to detect bidirectional communication (the Router IDs of all neighbors whose Hellos have been recently received) 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 1 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtr Priority | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | RouterDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
The OSPF Hello PacketInterface ID 💖 32-bit number uniquely identifying this interface among the collection of this router's interfaces. For example, in some implementations it may be possible to use the MIB-II IfIndex ([INTFMIB]).
Rtr Priority 👑 This router's Router Priority. Used in (Backup) Designated Router election. If set to 0, the router will be ineligible to become (Backup) Designated Router.
Options 🌈 The optional capabilities supported by the router, as documented in Section A.2.
HelloInterval ⏱️ The number of seconds between this router's Hello packets.
RouterDeadInterval 💀 The number of seconds before declaring a silent router down.
Designated Router ID 🫶 The sending router's view of the identity of the Designated Router for this network. The Designated Router is identified by its Router ID. It is set to 0.0.0.0 if there is no Designated Router.
Backup Designated Router ID 🧚 The sending router's view of the identity of the Backup Designated Router for this network. The Backup Designated Router is identified by its IP Router ID. It is set to 0.0.0.0 if there is no Backup Designated Router.
Neighbor ID 🍓 The Router IDs of each router on the network with neighbor state 1-Way or greater.
A.3.3. The Database Description Packet ✨
Okay bestie, Database Description packets are OSPF packet type 2 🎀. They get exchanged when an adjacency is being initialized, and their whole job is to describe the contents of the link-state database 🧚. One packet usually can't cover the whole database, so they use a poll-response procedure 💅. One router is the master and the other is the slave. The master sends the polls and the slave answers each one with its own Database Description packet. The responses get matched back to their polls by the packets' DD sequence numbers, which is lowkey 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| 3 | 2 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Interface MTU | 0 |0|0|0|0|0|I|M|MS|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| DD sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| ... |
The OSPF Database Description PacketThe format of the Database Description packet is very similar to both the Link State Request packet and the Link State Acknowledgment packet 🍓. All three are basically a list of items, and each item describes one piece of the link-state database. The sending of Database Description packets is documented in Section 10.8 of [OSPFV2]. The reception of them is documented in Section 10.6 of [OSPFV2] 📚.
Options The optional capabilities supported by the router, as documented in Section A.2. ✨
Interface MTU The size in bytes of the largest IPv6 datagram that can be sent out the associated interface without fragmentation. The MTUs of common Internet link types can be found in Table 7-1 of [MTUDISC] 🌈.
Interface MTU should be set to 0 in Database Description packets sent over virtual links. 🙈
I-bit The Init bit. When set to 1, this packet is the first in the sequence of Database Description packets 🦋.
M-bit The More bit. When set to 1, it indicates that more Database Description packets are to follow 🌸.
MS-bit The Master/Slave bit. When set to 1, it indicates that the router is the master during the Database Exchange process. Otherwise, the router is the slave 👑.
DD sequence number Used to sequence the collection of Database Description packets. The initial value (indicated by the Init bit being set) should be unique. The DD sequence number then increments until the complete database for both the master and slave routers has been exchanged 💜.
The rest of the packet is a (possibly partial) list of the link-state database's pieces. Each LSA in the database is described by its LSA header, which is documented in Appendix A.4.2 🧚. The LSA header has everything needed to uniquely identify both the LSA and the LSA's current instance 💅.
A.3.4. The Link State Request Packet 🦋
Link State Request packets are OSPF packet type 3 🎀. After swapping Database Description packets with a neighboring router, a router might find out that parts of its link-state database are out-of-date 😭. That's where the Link State Request packet comes in, because it's used to ask the neighbor for the pieces of its database that are more up-to-date 💖. Multiple Link State Request packets may need to be used, so don't panic if one isn't enough 🫶.
A router that sends a Link State Request packet has a very specific instance of each database piece in mind. Each instance is defined by its LS sequence number, LS checksum, and LS age. Those fields aren't actually specified in the Link State Request packet itself, though 🙈. The router may even receive even more recent LSA instances in response ✨.
The sending of Link State Request packets is documented in Section 10.9 of [OSPFV2]. The reception of them is documented in Section 10.7 of [OSPFV2] 📚.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 3 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
The OSPF Link State Request PacketEach LSA being requested is specified by its LS type, Link State ID, and Advertising Router 🌈. Those three together uniquely identify the LSA, but they don't pin down a specific instance 💜. So Link State Request packets are understood to be requests for the most recent instance of the specified LSAs 👑.
A.3.5. The Link State Update Packet 💅
Link State Update packets are OSPF packet type 4, and they're the ones that actually implement the flooding of LSAs 🔥. Each Link State Update packet carries a collection of LSAs one hop further from their origin 🧚. Several LSAs can be squished into a single packet 🎀.
Link State Update packets are multicast on those physical networks that support multicast/broadcast 🦋. To make the flooding procedure reliable, flooded LSAs are acknowledged in Link State Acknowledgment packets ✨. If an LSA needs to be retransmitted, the retransmitted LSAs are always carried by unicast Link State Update packets 🫶. For more on the reliable flooding of LSAs, check Section 4.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 |
+- +-+
| ... |
The OSPF Link State Update Packet# LSAs The number of LSAs included in this update. 🔢
The body of the Link State Update packet is a list of LSAs 🌈. Each LSA begins with a common 20-byte header, which is described in Appendix A.4.2 💖. The detailed formats of the different types of LSAs are described in Appendix A.4 ✨.
A.3.6. The Link State Acknowledgment Packet ✨
okay so Link State Acknowledgment packets are OSPF packet type 5 🦋. To make flooding of LSAs reliable, flooded LSAs get acknowledged explicitly or implicitly 💖. Explicit acks happen by sending and receiving these Link State Acknowledgment packets. Sending them is documented in Section 13.5 of [OSPFV2], and receiving them is documented in Section 13.7 of [OSPFV2] 📚.
Multiple LSAs MAY be acknowledged in a single Link State Acknowledgment packet 🫶. Where the packet goes depends on the state of the sending interface and on who sent the matching Link State Update packet. It can go to the AllSPFRouters multicast address, the AllDRouters multicast address, or a neighbor's unicast address (see Section 13.5 of [OSPFV2] for details) 🌸.
The format is basically a cousin of the Data Description packet. The body of both is just a list of LSA headers 🧚.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 5 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |The OSPF Link State Acknowledgment Packet
Each acknowledged LSA is described by its LSA header 💅. That header is documented in Appendix A.4.2, and it holds all the info required to uniquely identify both the LSA and the LSA's current instance 🔥.
A.4. LSA Formats 🌈
This document defines eight distinct types of LSAs 💜. Every LSA starts with a standard 20-byte LSA header, which is explained in Appendix A.4.2. The sections that follow describe each LSA type individually ✨.
Each LSA describes a piece of the OSPF routing domain 🎀. Every router originates a router-LSA. A network-LSA is advertised for each link by its Designated Router. A router's link-local addresses are advertised to its neighbors in link-LSAs. IPv6 prefixes show up in intra-area-prefix-LSAs, inter-area-prefix-LSAs, AS-external-LSAs, and NSSA-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 common to a flooding scope end up with the same collection of LSAs for that scope. (See Section 4.5 for more on the flooding algorithm.) 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 yields a routing table (see Section 11 of [OSPFV2]). For the details on the routing table build process, see Section 4.8 🧠.
A.4.1. IPv6 Prefix Representation 💖
IPv6 addresses are bit strings of length 128 🌸. IPv6 routing protocols, and OSPF for IPv6 especially, advertise IPv6 address prefixes. Those prefixes are bit strings whose length can be anywhere from 0 to 128 bits, inclusive 🫶.
Inside OSPF, an IPv6 address prefix is always represented by three fields together: PrefixLength, PrefixOptions, and Address Prefix 👑. PrefixLength is the length in bits of the prefix. PrefixOptions is an 8-bit field describing various capabilities linked to the prefix (see Appendix A.4.1.1) ✨. Address Prefix is the prefix itself, encoded as an even multiple of 32-bit words and padded with zero bits as needed. That encoding consumes ((PrefixLength + 31) / 32) 32-bit words 🧚.
The default route is represented by a prefix of length 0 🍓.
Examples of IPv6 prefix representation in OSPF live in Appendix A.4.5, Appendix A.4.7, Appendix A.4.8, Appendix A.4.9, and Appendix A.4.10 📚.
A.4.1.1. Prefix Options 🎀
Each prefix gets advertised with an 8-bit field of capabilities 💅. These act as input to the various routing calculations. For example, they can say a prefix should be ignored in some cases, or that it should be marked as not readvertisable in others 🙈.
0 1 2 3 4 5 6 7
+--+--+--+--+--+-+--+--+
| | | |DN| P|x|LA|NU|
+--+--+--+--+--+-+--+--+The PrefixOptions Field 🦋
NU-bit 💜 : The "no unicast" capability bit. If it's set, the prefix should be excluded from IPv6 unicast calculations. If it's not set, the prefix should be included 💀.
LA-bit 🌸 : The "local address" capability bit. If it's set, the prefix is actually an IPv6 interface address of the Advertising Router. Advertisement of local interface addresses is described in Section 4.4.3.9. An implementation MAY also set the LA-bit for prefixes advertised with a host PrefixLength (128) 🫶.
x-bit 🙈 : This bit used to be defined as a "multicast" capability bit. The use was never adequately specified, though, and it has been deprecated for OSPFv3 😭. The bit should be set to 0 and ignored when received. It may be reassigned in the future 🔥.
P-bit ✨ : The "propagate" bit. It's set on NSSA area prefixes that should be readvertised by the translating NSSA area border [NSSA] 👑.
DN-bit 🌈 : This bit controls inter-area-prefix-LSA or AS-external-LSA re-advertisement in a VPN environment, as specified in [DN-BIT] 💖.
A.4.2. The LSA Header 🧚
All LSAs begin with a common 20-byte header 💅. This header holds enough info to uniquely identify the LSA: its LS type, Link State ID, and Advertising Router 🦋. Multiple instances of the same LSA can exist in the routing domain at once, so it matters which one is newer 🙈. To figure that out, you check the LS age, LS sequence number, and LS checksum fields, which also live 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The LSA Header 💜
LS Age ⏰ : The time in seconds since the LSA was originated.
LS Type 🌸 : The LS type field indicates the function the LSA performs. The high-order three bits of LS type encode generic properties of the LSA, while the remainder (called LSA function code) indicates the LSA's specific functionality. See Appendix A.4.2.1 for a detailed description of LS type 🧠.
Link State ID 🫶 : The originating router's identifier for the LSA. The combination of Link State ID, 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 equals the Router ID of the network's Designated Router ✨.
LS sequence number 🦋 : Successive instances of an LSA get successive LS sequence numbers. The sequence number can be used to detect old or duplicate LSA instances. See Section 12.1.6 in [OSPFV2] for more details 💖.
LS checksum 🌈 : The Fletcher checksum of the complete contents of the LSA, including the LSA header but excluding the LS age field. See Section 12.1.7 in [OSPFV2] for more details 💅.
length 🍓 : The length in bytes of the LSA. This includes the 20-byte LSA header 🧚.
A.4.2.1. LSA Type ✨
okay so the LS type field tells you what the LSA is actually for 💅 The high-order three bits encode generic properties of the LSA, and the rest (called the LSA function code) covers its specific functionality. Here's the layout:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|U |S2|S1| LSA Function Code |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
LSA TypeThe U-bit is the "what do I do if I don't recognize this?" bit 🙈 It tells a router how to handle an LSA whose function code it doesn't understand:
U-bit LSA Handling
-------------------------------------------------------------
0 Treat the LSA as if it had link-local flooding scope
1 Store and flood the LSA as if the type is understood
U-BitThe S1 and S2 bits set the flooding scope of the LSA, meaning how far it gets passed along:
S2 S1 Flooding Scope
-------------------------------------------------------------
0 0 Link-Local Scoping - Flooded only on originating link
0 1 Area Scoping - Flooded only in originating area
1 0 AS Scoping - Flooded throughout AS
1 1 Reserved
Flooding ScopeThe LSA function codes are defined as follows. Their origination and processing are described elsewhere in this document, except for the NSSA-LSA (see [NSSA]) and 0x2006, which MOSPF used to use (see [MOSPF]). MOSPF has been deprecated for OSPFv3 🥀 Also, each function code implies a specific setting for the U, S1, and S2 bits, as you can see 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 Deprecated (may be reassigned)
7 0x2007 NSSA-LSA
8 0x0008 Link-LSA
9 0x2009 Intra-Area-Prefix-LSA
LSA Function CodeA.4.3. Router-LSAs 🏠
okay, router-LSAs are the main character of the area 👑 They have LS type equal to 0x2001. Each router in an area originates one or more of them, and together they describe the state and cost of the router's interfaces to that area. For how to build them, see Section 4.4.3.2. Router-LSAs only get flooded throughout a single area, so they never leave their home turf 🌸
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |0|0|1| 1 |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |Nt|x|V|E|B| Options |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Router-LSA FormatA single router can originate one or more router-LSAs, and 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 in all router-LSAs from one originator. But if they don't match, the values in the LSA with the lowest Link State ID win ✨ When a router sends more than one router-LSA, the links get processed as if they were all concatenated into one big LSA.
Bit V When set, the router is an endpoint of one or more fully adjacent virtual links that use the described area as their transit area (V is for virtual link endpoint).
Bit E When set, the router is an AS boundary router (E is for external).
Bit B When set, the router is an area border router (B is for border).
Bit x This bit used to be used by MOSPF (see [MOSPF]) and has been deprecated for OSPFv3. The bit should be set to 0 and ignored when received. It may be reassigned in the future 🥀
Bit Nt When set, the router is an NSSA border router that unconditionally translates NSSA-LSAs into AS-external-LSAs (Nt stands for NSSA translation). These routers have their NSSATranslatorRole area configuration parameter set to Always. (See [NSSA].)
Options The optional capabilities the router supports, as documented in Appendix A.2.
The following fields describe each router interface. The Type field says what kind of interface it is, and it can be a transit network, a point-to-point connection to another router, or a virtual link. The values of all the other fields describing a router interface depend on that Type field 🦋
Type The kind of interface being described. One of the following:
Type Description
---------------------------------------------------
1 Point-to-point connection to another router
2 Connection to a transit network
3 Reserved
4 Virtual link
Router Link TypesMetric The cost of using this router interface for outbound traffic.
Interface ID The Interface ID assigned to the interface being described. See Section 4.1.2 and Appendix C.3.
Neighbor Interface ID The Interface ID the neighbor router has associated with the link, as advertised in the neighbor's Hello packets. For transit (type 2) links, the neighbor described is the link's Designated Router. For other link types, the sole adjacent neighbor is described.
Neighbor Router ID The Router ID of the neighbor router. For transit (type 2) links, the neighbor described is the link's Designated Router. For other link types, the sole adjacent neighbor is described.
For transit (Type 2) links, the combo of Neighbor Interface ID and Neighbor Router ID lets you find the network-LSA for the attached link in the link-state database 🔍💜
A.4.4. Network-LSAs 🌐
Network-LSAs have LS type equal to 0x2002. One gets originated for each broadcast and NBMA link in the area that has two or more adjacent routers 🫶 The link's Designated Router is the one that originates it, and the LSA describes every router attached to the link, the Designated Router included. Its Link State ID field is set to the Interface ID 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 a network-LSA 🧮 For how to construct them, see Section 4.4.3.3.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |0|0|1| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attached Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Network-LSA FormatAttached Router The Router IDs of each router attached to the link. Strictly speaking, only the routers that are fully adjacent to the Designated Router get listed, and the Designated Router lists itself too 👑 You can work out how many routers are included from the LSA header's length field.
A.4.5. Inter-Area-Prefix-LSAs ✨
okay bestie, inter-area-prefix-LSAs have LS type 0x2003 💖 they're basically the IPv6 version of OSPF for IPv4's type 3 summary-LSAs (see Section 12.4.3 of [OSPFV2]) 🦋 area border routers originate them, and they describe routes to IPv6 address prefixes that belong to other areas 🌸 you get a separate inter-area-prefix-LSA for each IPv6 address prefix, no sharing! for how to construct them, see Section 4.4.3.4.
for stub areas, these LSAs can also describe a (per-area) default route 🧚 default summary routes are used in stub areas instead of flooding a complete set of external routes, which is so iconic. when you're describing a default summary route, the inter-area-prefix-LSA's PrefixLength is set to 0 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |0|0|1| 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inter-Area-Prefix-LSA FormatMetric: the cost of this route 📏 it's expressed in the same units as the interface costs in router-LSAs. when the inter-area-prefix-LSA is describing a route to a range of addresses (see Appendix C.2), the cost is set to the maximum cost to any reachable component of the address range.PrefixLength,PrefixOptions, andAddress Prefix: the representation of the IPv6 address prefix, as described in Appendix A.4.1 🎀
A.4.6. Inter-Area-Router-LSAs 🌈
inter-area-router-LSAs have LS type 0x2004 🫶 these are the IPv6 equivalent of OSPF for IPv4's type 4 summary-LSAs (see Section 12.4.3 of [OSPFV2]). area border routers originate them, and they describe routes to AS boundary routers in other areas. wondering why we need to advertise the location of each ASBR? go consult Section 16.4 in [OSPFV2] 🤓 each LSA describes a route to a single router. for construction details, see Section 4.4.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |0|0|1| 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inter-Area-Router-LSA FormatOptions: the optional capabilities supported by the router, as documented in Appendix A.2 ⚙️Metric: the cost of this route, expressed in the same units as the interface costs in router-LSAs 💸Destination Router ID: the Router ID of the router being described by the LSA 🪪
A.4.7. AS-External-LSAs 🌍
AS-external-LSAs have LS type 0x4005 🛸 they're originated by AS boundary routers and describe destinations external to the AS. each LSA describes a route to a single IPv6 address prefix. for construction details, see Section 4.4.3.6.
AS-external-LSAs can be used to describe a default route 🏠 default routes are used when no specific route exists to the destination. when describing a default route, the AS-external-LSA's PrefixLength is set to 0 🙌
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |0|1|0| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |E|F|T| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Referenced LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- Forwarding Address (Optional) -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Link State ID (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AS-external-LSA Formatbit E: the type of external metric 🧮 if bit E is set, the metric specified is a Type 2 external metric. this means the metric is considered larger than any intra-AS path. if bit E is zero, the specified metric is a Type 1 external metric. this means that it is expressed in the same units as other LSAs (i.e., the same units as the interface costs in router-LSAs).bit F: if set, a Forwarding Address has been included in the LSA 🧭bit T: if set, an External Route Tag has been included in the LSA 🏷️Metric: the cost of this route. the interpretation depends on the external type indication (bit E above) 💅PrefixLength,PrefixOptions, andAddress Prefix: the representation of the IPv6 address prefix, as described in Appendix A.4.1 🎀Referenced LS Type: if non-zero, an LSA with this LS type is to be associated with this LSA (see Referenced Link State ID below) 🔗Forwarding address: a fully qualified IPv6 address (128 bits) 📍 it's included in the LSA if and only if bit F has been set. if included, data traffic for the advertised destination will be forwarded to this address. it MUST NOT be set to the IPv6 Unspecified Address (0:0:0:0:0:0:0:0) or an IPv6 Link-Local Address (Prefix FE80/10). while OSPFv3 routes are normally installed with link-local addresses, an OSPFv3 implementation advertising a forwarding address MUST advertise a global IPv6 address. this global IPv6 address may be the next-hop gateway for an external prefix or may be obtained through some other method (e.g., configuration). 🫠External Route Tag: a 32-bit field that MAY be used to communicate additional information between AS boundary routers 🎟️ it's included in the LSA if and only if bit T has been set.Referenced Link State ID: included if and only if Reference LS Type is non-zero. if included, additional information concerning the advertised external route can be found in the LSA having LS type equal to "Referenced LS Type", Link State ID equal to "Referenced Link State ID", and Advertising Router the same as that specified in the AS-external-LSA's link-state header. this additional information is not used by the OSPF protocol itself. it may be used to communicate information between AS boundary routers. the precise nature of such information is outside the scope of this specification. 🕵️
all, none, or some of the fields labeled Forwarding address, External Route Tag, and Referenced Link State ID MAY be present in the AS-external-LSA (as indicated by the setting of bit F, bit T, and Referenced LS Type respectively) 🧩 when present, Forwarding Address always comes first, External Route Tag next, and the Referenced Link State ID last 🥹
A.4.8. NSSA-LSAs 🌸
NSSA-LSAs have LS type 0x2007 🌷 these are originated by AS boundary routers within an NSSA and describe destinations external to the AS that may or may not be propagated outside the NSSA (refer to [NSSA]). other than the LS type, their format is exactly the same as AS-external LSAs as described in Appendix A.4.7 👯
a global IPv6 address MUST be selected as forwarding address for NSSA-LSAs that are to be propagated by NSSA area border routers 🚦 the selection should proceed the same as OSPFv2 NSSA support [NSSA] with additional checking to ensure IPv6 link-local address are not selected 🙈
A.4.9. Link-LSAs ✨
Okay bestie, link-LSAs have LS type 0x0008 💜 A router makes a separate link-LSA for each attached physical link. They are super local 🦋 they have link-local flooding scope, so they are never flooded beyond the link they belong to. Link-LSAs do three jobs:
- They hand the router's link-local address to every other router on the link 🌸
- They tell the other routers on that link which IPv6 prefixes go with the link 🎀
- They let the router advertise a set of Options bits that show up in the network-LSA the Designated Router builds on a broadcast or NBMA link 👑
For how to actually build link-LSAs, check out Section 4.4.3.8.
A link-LSA's Link State ID is set equal to the originating router's Interface ID on that 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 Priority | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- Link-local Interface Address -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # prefixes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link-LSA FormatHere's the field rundown 💅
- Rtr Priority: the Router Priority of the interface that attaches the originating router to the link.
- Options: the set of Options bits the router would like set in the network-LSA that the Designated Router will originate on broadcast or NBMA links.
- Link-local Interface Address: the originating router's link-local interface address on the link.
- # prefixes: how many IPv6 address prefixes are in the LSA.
After that, the rest of the link-LSA is a list of IPv6 prefixes tied to the link 🌈
- PrefixLength, PrefixOptions, and Address Prefix: this is how an IPv6 address prefix gets represented, as covered in Appendix A.4.1.
A.4.10. Intra-Area-Prefix-LSAs 🍓
Intra-area-prefix-LSAs have LS type 0x2009 🌸 A router uses them to advertise one or more IPv6 address prefixes linked to a local router address, an attached stub network segment, or an attached transit network segment. In IPv4, the first two lived in the router's router-LSA and the last one lived in a network-LSA. In OSPF for IPv6, all the addressing info that used to be in router-LSAs and network-LSAs has been taken out and now lives in intra-area-prefix-LSAs. It's giving glow-up 🦋 For how to build an intra-area-prefix-LSA, check out Section 4.4.3.9.
A router can originate multiple intra-area-prefix-LSAs for each router or transit network 💖 Each one is told apart by its own unique 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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Intra-Area-Prefix LSA FormatField time 🎀
- # prefixes: how many IPv6 address prefixes are in the LSA.
- Referenced LS Type, Referenced Link State ID, and Referenced Advertising Router: these point to the router-LSA or network-LSA that the IPv6 address prefixes should be linked with. If Referenced LS Type is
0x2001, the prefixes go with a router-LSA, Referenced Link State ID should be0, and Referenced Advertising Router should be the originating router's Router ID. If Referenced LS Type is0x2002, the prefixes go 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 is a list of IPv6 prefixes tied to the router or transit link, plus their costs 🌟
- PrefixLength, PrefixOptions, and Address Prefix: the IPv6 address prefix representation, as described in Appendix A.4.1.
- Metric: the cost of this prefix, expressed in the same units as the interface costs in router-LSAs.
Appendix B. Architectural Constants 🦋
The architectural constants for OSPF are defined in Appendix B of [OSPFV2] ✨ The only difference for OSPF for IPv6 is that DefaultDestination is encoded as a prefix with length 0 (see Appendix A.4.1). That's it, that's the tea 🫶
Appendix C. Configurable Constants 💜
OSPF has quite a few configurable parameters 🌈 They're listed below and grouped into general functional categories (area parameters, interface parameters, and so on). Some sample values are given for a few of them.
Some parameter settings have to stay consistent across groups of routers. For example, every router in an area must agree on that area's parameters. Likewise, all routers attached to a network must agree on that network's HelloInterval and RouterDeadInterval 👑
Some parameters might be decided by router algorithms outside this spec (for example, the address of a host connected to the router over a SLIP line). From OSPF's point of view, those items are still configurable 🧚
C.1. Global Parameters 🌸
In general, a separate copy of the OSPF protocol runs for each area 💅 Because of that, most configuration parameters are defined per area. 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 changes, the router's OSPF software should be restarted before the new Router ID takes effect. Before restarting because of a Router ID change, the router should flush its self-originated LSAs from the routing domain (see Section 14.1 of [OSPFV2]). Otherwise, they will persist for up to MaxAge seconds 🙈
Because the Router ID is smaller than an IPv6 address, it can't be set to one of the router's IPv6 addresses (which is commonly done for IPv4) 💀 Possible Router ID assignment procedures for IPv6 include: a) assigning the IPv6 Router ID as one of the router's IPv4 addresses, or b) assigning IPv6 Router IDs through some local administrative procedure (similar to how manufacturers assign product serial numbers) 🎀
The Router ID of 0.0.0.0 is reserved and SHOULD NOT be used. 🚫 Bestie, don't use 0.0.0.0 as a Router ID!
C.2. Area Parameters ✨
okay bestie, the golden rule of areas is that every router in an area has to agree on that area's config 🫶. If two routers disagree, adjacencies can't form between them, and then routing info AND data traffic get hindered 😭. The following items must be configured for an area:
- Area ID: a 32-bit number that identifies the area. Area ID
0is 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 the address range 💜- Status: set to either
AdvertiseorDoNotAdvertise. Routing info gets condensed at area boundaries, so outside the area, at most a single route is advertised (via a inter-area-prefix-LSA) for each address range. That route only gets advertised if the range's Status isAdvertise. Unadvertised ranges let certain networks be intentionally hidden from other areas 🙈 Status is set toAdvertiseby default ✨
- ExternalRoutingCapability: whether AS-external-LSAs will be flooded into/throughout the area. If AS-external-LSAs are excluded from the area, the area is called a stub area or NSSA. Inside stub areas, routing to external destinations is based solely on a default inter-area route. The backbone cannot be configured as a stub or NSSA area, and virtual links cannot be configured through stub or NSSA areas either 🦋 For more info, see Section 3.6 of [OSPFV2] and [NSSA] 📖
- StubDefaultCost: if the area has been configured as a stub area and the router itself is an area border router, then the StubDefaultCost 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 [OSPFV2] for more 💅
- NSSATranslatorRole and TranslatorStabilityInterval: these area parameters are described in Appendix D of [NSSA]. On top of that, an NSSA Area Border Router (ABR) is also required to allow configuration of whether or not an NSSA default route is advertised in an NSSA-LSA. If it is advertised, its metric and metric type are configurable. Those requirements are also described in Appendix D of [NSSA] 🌈
- ImportSummaries: when set to enabled, prefixes external to the area get imported into the area via the advertisement of inter-area-prefix-LSAs. When set to disabled, inter-area routes are not imported into the area. The default setting is enabled. This parameter is only valid for stub or NSSA areas 🍓
C.3. Router Interface Parameters 🎀
some of the configurable router interface parameters (like Area ID, HelloInterval, and RouterDeadInterval) actually imply properties of the attached links, so these parameters must be consistent across all the routers attached to that link 🔥 The parameters that must be configured for a router interface are:
- IPv6 link-local address: the IPv6 link-local address associated with this interface. May be learned through auto-configuration 🧚
- Area ID: the OSPF area that the attached link belongs to 🌸
- Instance ID: the OSPF protocol instance associated with this OSPF interface. Defaults to
0💖 - Interface ID: a 32-bit number uniquely identifying this interface among this router's interfaces. For example, some implementations may be able to use the MIB-II IfIndex ([INTFMIB]) ✨
- IPv6 prefixes: the list of IPv6 prefixes to associate with the link. These will be advertised in intra-area-prefix-LSAs 🦋
- Interface output cost(s): the cost of sending a packet on the interface, expressed in the link-state metric. This is advertised as the link cost for this interface in the router's router-LSA. The interface output cost MUST always be greater than
0👑 - RxmtInterval: the number of seconds between LSA retransmissions for adjacencies belonging to this interface. Also used when retransmitting Database Description and Link State Request packets. 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:
5seconds 🌈 - 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 take into account the transmission and propagation delays of the interface. It MUST be greater than
0. Sample value for a local area network:1second 🧚 - Router Priority: an 8-bit unsigned integer. When two routers attached to a network both try to become the Designated Router, the one with the highest Router Priority takes precedence. If there's still a tie, the router with the highest Router ID wins 👑 A router whose Router Priority is set to
0is ineligible to become the Designated Router on the attached link. Router Priority is only configured for interfaces to broadcast and NBMA networks 💅 - HelloInterval: the length of time, in seconds, between Hello packets that the router sends on the interface. This value is advertised in the router's Hello packets. It MUST be the same for all routers attached to a common link. The smaller the HelloInterval, the faster topological changes get detected, but more OSPF routing protocol traffic will ensue ⚡ Sample value for an X.25 PDN:
30seconds. Sample value for a local area network (LAN):10seconds 🍓 - RouterDeadInterval: after ceasing to hear a router's Hello packets, the number of seconds before its neighbors declare the router down. This is also advertised in the router's Hello packets, in their RouterDeadInterval field. It should be some multiple of the HelloInterval (e.g.,
4). This value again MUST be the same for all routers attached to a common link 💀 - LinkLSASuppression: indicates whether or not origination of a link-LSA is suppressed. If set to "enabled" and the interface type is not broadcast or NBMA, the router will not originate a link-LSA for the link. That means other routers on the link will figure out the router's next-hop address using a mechanism other than the link-LSA (see Section 4.8.2) 🫶 The default value is "disabled" for interface types described in this specification. It is implicitly "disabled" if the interface type is broadcast or NBMA. Future interface types MAY specify a different default 🔮
C.4. Virtual Link Parameters 🦋
virtual links are used to restore or increase connectivity of the backbone 🌉 They may be configured between any pair of area border routers that have interfaces to a common (non-backbone) area. The virtual link appears as a point-to-point link with no global IPv6 addresses in the graph for the backbone. The virtual link must be configured in both of the area border routers 💖
a virtual link shows up in router-LSAs (for the backbone) as if it were a separate router interface to the backbone, so it has most of the parameters associated with a router interface (see Appendix C.3) ✨ Virtual links don't have link-local addresses. Instead, they use one of the router's global-scope IPv6 addresses as the IP source in OSPF protocol packets it sends on the virtual link 🧚 Router Priority is not used on virtual links. Interface output cost isn't configured on virtual links either, but gets dynamically set to the cost of the transit area intra-area path between the two endpoint routers 🍓 The parameter RxmtInterval may be configured and should be well over the expected round-trip delay between the two routers. This can be hard to estimate for a virtual link, so it's better to err on the side of making it too long 🙈
a virtual link is defined by two configurable parameters: the Router ID of the virtual link's other endpoint, and the (non-backbone) area that the virtual link traverses, which is called the virtual link's transit area 👑 Virtual links cannot be configured through stub or NSSA areas. Also, an Instance ID may be configured for virtual links from different protocol instances so they can use the same transit area, without needing different Router IDs for demultiplexing 🌈
C.5. NBMA Network Parameters 💜
OSPF treats an NBMA network much like it treats a broadcast network. Since there may be many routers attached to the network, a Designated Router is selected for the network. That Designated Router then originates a network-LSA listing all routers attached to the NBMA network 🫶
but because there's no broadcast capability, it may be necessary to use configuration parameters in the Designated Router selection. These parameters only need to be configured in routers that are themselves eligible to become the Designated Router (i.e., routers whose Router Priority for the network is non-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, its eligibility to become the Designated Router must also be defined. When an interface to an NBMA network first comes up, the router only sends Hello packets to those neighbors eligible to become the Designated Router, until a Designated Router is elected 🦋
- PollInterval: if a neighboring router has become inactive (Hello packets haven't been seen for RouterDeadInterval seconds), it may still be necessary to send Hello packets to the dead neighbor. These Hello packets are sent at the reduced rate PollInterval, which should be much larger than HelloInterval. Sample value for a PDN X.25 network:
2minutes ⏰
C.6. Point-to-Multipoint Network Parameters ⭐
on point-to-multipoint networks, it may be necessary to configure the set of neighbors that are directly reachable over the point-to-multipoint network. Each neighbor is configured with its Router ID and IPv6 link-local address on the network 🧚 Designated Routers are not elected on point-to-multipoint networks, so the Designated Router eligibility of configured neighbors isn't defined 🌸
C.7. Host Route Parameters ✨
okay so host prefixes get advertised in intra-area-prefix-LSAs 💅 They can point at a few different things: local router addresses, router interfaces to point-to-point networks, looped router interfaces, or IPv6 hosts that are directly connected to the router (like through a PPP connection 🎀). For every host directly connected to the router, these items must be configured:
- Host IPv6 prefix: an IPv6 prefix that belongs to the directly connected host 🧚 It must not be a valid IPv6 global prefix. no cap, this one matters!
- Cost of link to host: the cost of sending a packet to the host, measured in link-state metric terms 📊 The host probably has only one connection to the Internet, so the configured cost(s) are unimportant in a lot of cases. Basically they won't change routing at all 🙈
- Area ID: the OSPF area that the host's prefix belongs to 🌸
Authors' Addresses
Rob Coltun
Acoustra Productions
3204 Brooklawn Terrace
Chevy Chase, MD 20815
USA
Dennis Ferguson
Juniper Networks
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
USA
EMail: dennis@juniper.net
John Moy
Sycamore Networks, Inc
10 Elizabeth Drive
Chelmsford, MA 01824
USA
EMail: jmoy@sycamorenet.com
Acee Lindem (editor)
Redback Networks
102 Carric Bend Court
Cary, NC 27519
USA
EMail: acee@redback.comFull Copyright Statement
Copyright (C) The IETF Trust (2008) 💖
This document is subject to the rights, licenses and restrictions contained in BCP 78. Except as set forth there, the authors keep all their rights 🎀
This document and the information in it are provided on an "AS IS" basis. THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF doesn't take a position on whether any Intellectual Property Rights or other rights that someone might claim for the technology in this document are valid or in scope 🧠 It also doesn't say whether any license under those rights might be available, and it hasn't made any independent effort to find those rights. Info on how rights work for RFC documents is in BCP 78 and BCP 79 📚
Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses that will be made available, or the result of an attempt to get a general license or permission for implementers or users to use those proprietary rights, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr 🦋
The IETF invites anyone interested to tell it about any copyrights, patents or patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 🫶 Thank you, bestie, that's the whole doc! ✨👑
📦 where this page comes from
- ietf: rfc5340 2008-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms