OSPFv3 vs OSPFv2 — protocol differences, address family separation, new LSA types, R-bit

OSPFv2 and OSPFv3 share a name and an algorithm but diverge in almost every operational detail. An operator who treats them as parallel implementations of the same protocol misses the architectural shift and ships configurations that work on one but not the other.

This lesson is the side-by-side reference: a table of differences, a walk through the new LSA types, the R-bit forwarding-plane implication, the authentication model change, and the dual-stack deployment decisions that follow.

The comparison table

The table is dense but every row has operational consequences. The rest of this lesson walks through the rows that matter most.

Address family separation

OSPFv3 is an IPv6-only protocol. OSPFv2 is an IPv4-only protocol. Neither carries the other address family natively.

The natural question is: why not extend OSPFv2 to carry IPv6? The answer is RFC 5838, which defined an address-family extension for OSPFv2. The mechanism works (an OSPFv2 process can carry IPv4 and IPv6 prefixes by tagging LSAs with an address-family identifier). FRR does not implement RFC 5838 by default in VyOS 1.5 LTS; the production answer is to run OSPFv2 for IPv4 and OSPFv3 for IPv6.

flowchart TB
  subgraph "OSPFv2 for IPv4 (ospfd)"
    A1["ipv4 LSDB"]
    A2["ipv4 RIB"]
  end
  subgraph "OSPFv3 for IPv6 (ospf6d)"
    B1["ipv6 LSDB"]
    B2["ipv6 RIB"]
  end
  subgraph "RFC 5838 OSPFv2-AF (not used in VyOS 1.5 LTS)"
    C1["unified LSDB<br/>AF-tagged"]
    C2["unified RIB"]
  end
  A1 --> A2
  B1 --> B2
  C1 --> C2

The VyOS 1.5 LTS convention is the two-process model:

# OSPFv2 for IPv4
set protocols ospf parameters router-id 10.255.0.1
set protocols ospf area 0 network 10.0.0.0/24

# OSPFv3 for IPv6 (separate process, separate router-id convention)
set protocols ospfv3 parameters router-id 10.255.0.1
set protocols ospfv3 area 0 interface eth0

The two processes share the router-id convention (10.255.0.1 on both) so an operator’s runbook reads cleanly, but the router-id is otherwise separate.

Per-link vs per-subnet

The OSPFv2 model is per-subnet: the network statement matches the interface’s primary or secondary IPv4 address, and matched interfaces are enabled into OSPFv2.

The OSPFv3 model is per-link: the interface is enabled into the area; the protocol discovers the IPv6 prefixes via Type 8 and Type 9 LSAs.

The operational consequence: OSPFv3 does not need to know which prefix is on the interface. An IPv6 link can have many prefixes (global unicast, unique-local, link-local, plus anycast or experimental prefixes); OSPFv3 discovers them all and advertises them all via Type 9 LSAs. The operator does not write network statements for OSPFv3.

flowchart LR
  subgraph "OSPFv2 model (per-subnet)"
    OA["area 0 network 10.0.0.0/24"]
    OA --> MA1["match eth0 10.0.0.1"]
    OA --> MA2["match eth1 10.0.1.1"]
    OA -. "no match" .-> MA3["eth2 192.168.1.1"]
  end
  subgraph "OSPFv3 model (per-link)"
    OB["area 0 interface eth0"]
    OB --> MB1["discover all prefixes on eth0"]
    OB --> MB2["Type 8 Link-LSA for each prefix"]
    OB --> MB3["Type 9 Intra-Area-Prefix-LSA for each prefix"]
  end

New LSA types

Three new LSA types appear in OSPFv3: Type 8 (Link-LSA), Type 9 (Intra-Area-Prefix-LSA), and the revised Type 1 (Router-LSA) which no longer carries the prefix.

Type 8 Link-LSA

Type 8 LSAs are flooded only on the local link, never beyond the link. They advertise the IPv6 prefixes on the link and the link-local address of the originating router. The Type 8 exists because OSPFv3 needs a way to advertise a prefix to neighbours on the link without flooding the prefix to the entire area; the Type 9 does the area-flooding.

# Diagnostic
show ipv6 ospf6 database link
# Link-LSAs visible only for the local link's interfaces

Type 9 Intra-Area-Prefix-LSA

Type 9 LSAs are flooded area-wide. They say “the prefix 2001:db8:1::/64 lives on the link advertised by Type 1 LSA X.” The Type 9 is what carries the IPv6 prefix in OSPFv3.

# Diagnostic
show ipv6 ospf6 database intra-prefix
# Type 9 LSAs visible area-wide

Type 1 Router-LSA (revised)

Type 1 LSAs in OSPFv3 carry topology only: which router is connected to which link, the metric of each link, the interface-id, and the Options bits (U-bit, S-bit, R-bit). They do not carry the IPv6 prefix; the prefix lives in Type 9.

# Diagnostic
show ipv6 ospf6 database router
# Type 1 LSAs visible area-wide, no prefix field

The three types form a chain: Type 1 says “R1 is connected to link X”, Type 8 says “the prefix 2001:db8:1::/64 is on link X”, Type 9 says “the prefix 2001:db8:1::/64 belongs to the link referenced by Type 1 LSA Y.” The receiving router stitches them together to install the prefix.

flowchart LR
  subgraph "R1 originates"
    L1["Type 1: R1 connected to link X<br/>(topology)"]
    L8["Type 8: link X carries 2001:db8:1::/64<br/>(per-link)"]
    L9["Type 9: 2001:db8:1::/64 belongs to link X<br/>(per-area)"]
  end
  subgraph "R2 receives"
    LSDB["R2 LSDB"]
    INSTALL["install 2001:db8:1::/64<br/>via R1's link X"]
  end
  L1 --> LSDB
  L8 --> LSDB
  L9 --> LSDB
  LSDB --> INSTALL

The R-bit in Type 3 Summary-LSAs

The R-bit (“Router-reachable”) is a new bit in the Options field of OSPFv3 LSAs. It is most consequential in Type 3 Summary-LSAs.

The R-bit is set when the originating router is participating in forwarding. A downstream router that receives a Type 3 with R-bit set can trust the prefix; SPF will install it. A Type 3 with R-bit clear means the originator is not forwarding; the downstream router knows the prefix is advertised but unreachable.

flowchart TB
  subgraph "Backbone area 0"
    ABR["ABR router-id 10.255.0.4"]
  end
  subgraph "Area 1"
    INT["Transit-only router<br/>router-id 10.255.0.5<br/>R-bit CLEAR (not forwarding)"]
    EDGE["Edge router<br/>router-id 10.255.0.6<br/>R-bit SET"]
  end
  ABR -- "Type 3 Summary 2001:db8:1::/64<br/>R-bit SET (ABR forwards)" --> EDGE
  INT -. "R-bit clear: no Type 3 forwarded" .-> ABR
  ABR -- "Type 3 Summary 2001:db8:2::/64<br/>R-bit CLEAR (via INT)" --> EDGE
  EDGE -. "SPF installs only SET-bit routes" .-> EDGE

The operational consequence: a transit-only router (a router in the area that has no transit traffic but participates in OSPFv3 for LSDB exchange) clears the R-bit on its originated Type 1 LSAs. The downstream router’s SPF runs but does not install the prefix in the RIB because the R-bit is clear.

The most common production case is a router in a stub area that is reachable but is not the forwarding exit for the area. The R-bit prevents the downstream router from installing a prefix that the transit-only router cannot actually deliver.

Authentication

OSPFv2 had built-in authentication: simple-text (insecure, removed in many deployments), MD5, and SHA. The authentication was carried in the OSPF header.

OSPFv3 abandoned this mechanism. The OSPFv3 protocol no longer wants to be in the authentication business; the security is provided by IPsec AH/ESP at the IP layer.

RFC 7166 (2014) added the OSPFv3 authentication trailer, a mechanism similar to OSPFv2’s trailer. It is supported in VyOS 1.5 LTS via:

set protocols ospfv3 area 0 authentication ipsec spi 256 algorithm sha1
set protocols ospfv3 area 0 authentication ipsec spi 256 key ascii SECRET

For deployments that need OSPFv3 authentication without the trailer, IPsec AH in transport mode is the alternative.

flowchart LR
  subgraph "OSPFv2 model"
    OA["OSPFv2 packet<br/>+ Auth Trailer (MD5 / SHA)<br/>authenticated in-protocol"]
  end
  subgraph "OSPFv3 model"
    OB["IPv6 packet + OSPFv3<br/>IPsec AH/ESP at IP layer<br/>OR<br/>OSPFv3 Auth Trailer (RFC 7166)"]
  end
  OA --> O1["deployment: simple<br/>deployment: complex<br/>vulnerable to replay if MD5"]
  OB --> O1b["deployment: complex<br/>deployment: simple<br/>vulnerable to replay if MD5"]

The operational difference: in OSPFv2 the operator adds one configuration line per area; in OSPFv3 the operator either adds RFC 7166 lines (similar complexity to OSPFv2) or configures IPsec (higher complexity but more flexible).

Configuration cross-reference

The OSPFv2 to OSPFv3 configuration translation:

The patterns are parallel but the OSPFv3 block uses interface where OSPFv2 uses network. The authentication is structured differently.

Diagnostic cross-reference

The OSPFv3 command set uses ipv6 ospf6 consistently (the 6 distinguishes the OSPFv3 process from the IPv4 OSPFv2). The tcpdump filter uses proto ospf6 (not proto 89, which would match OSPFv2).

Dual-stack deployment decisions

A dual-stack deployment (IPv4 + IPv6 on the same link) needs:

1. OSPFv2 for IPv4. Standard OSPFv2 configuration; no IPv6.
2. OSPFv3 for IPv6. Standard OSPFv3 configuration; IPv6 only.
3. Redistribution between them if needed. If a route must move from one address family to the other (rare; usually a separate default route per family suffices), configure redistribution blocks in both directions.
4. Matching authentication. If OSPFv2 uses MD5 and OSPFv3 uses IPsec, configure both. Mismatched authentication fragments the adjacencies per family.

flowchart LR
  subgraph "Dual-stack deployment"
    OA1["OSPFv2 process<br/>IPv4 LSDB"]
    OA2["OSPFv3 process<br/>IPv6 LSDB"]
    RED1["redistribute (optional)"]
  end
  OA1 -- "redistribute" --> RED1 --> OA2
  subgraph "Decision points"
    D1["Use both for dual-stack?"]
    D2["Run RFC 5838 OSPFv2-AF instead?"]
    D3["Need route-leak between families?"]
  end
  D1 -- "yes" --> OA1
  D2 -- "no (VyOS 1.5 LTS convention)" --> OA1
  D3 -- "yes" --> RED1

The VyOS 1.5 LTS convention is the two-process model. RFC 5838 OSPFv2-AF is technically an option but is not the default in FRR; the operator who wants it configures it explicitly.

Production failure modes specific to the comparison

• Single-process assumption. The operator enables ospfd and expects IPv6 routing to work. It does not. The fix is to also enable ospf6d with set protocols ospfv3 ....
• Routing policy applied to one family only. The operator configures a route-map for OSPFv2 redistribution but forgets to apply it for OSPFv3. The OSPFv3 routes are redistributed unfiltered. The fix is to apply the route-map to both processes.
• Per-subnet mental model on OSPFv3. The operator writes set protocols ospfv3 area 0 network 2001:db8::/64. The command is rejected. The fix is set protocols ospfv3 area 0 interface eth0.
• R-bit confusion. The operator sees a Type 3 Summary-LSA in the LSDB but no route in the RIB. The Type 3 has R-bit clear. The fix is to recognise the R-bit and trace the forwarding path back to the originator.
• Authentication model confusion. The operator configures OSPFv2 MD5 authentication and expects the same configuration to apply to OSPFv3. It does not. The fix is to configure OSPFv3 authentication separately (RFC 7166 trailer or IPsec).

Rollback

The rollback is per-family:

# OSPFv2 rollback
delete protocols ospf area 0 interface eth0
commit
save

# OSPFv3 rollback
delete protocols ospfv3 area 0 interface eth0
commit
save

# Or full rollback
rollback N
commit

The two processes are independent. A change to OSPFv2 does not affect OSPFv3 and vice versa; the operator can roll back one without affecting the other.

Production discipline

Cross-course references

The OSPFv3 concept lesson vyos-xxi-01-ospfv3-concept covers the protocol-level changes this lesson builds on. The OSPFv3 configuration lesson vyos-xxi-02-ospfv3-config covers the VyOS configuration tree. The OSPF fundamentals lessons vyos-xviii-03-lsa-types (LSA types), vyos-xviii-04-areas (area design), and vyos-xix-04-ospf-redistribute (redistribution) cover the shared concepts. The OSPF configuration lessons vyos-xix-01-ospf-basics through vyos-xix-06-ospf-cost-tuning cover the OSPFv2 idiom that this lesson compares against.

Quiz