skip to content

Why did OSPFv3 take IPv6 prefixes out of router-LSAs and network-LSAs and put them in Intra-Area-Prefix-LSAs, and what does that buy?

level: seniorimportance: must knowfreq 20%

answer

  1. graph vertices versus graph leaves
  2. a prefix change leaves the graph alone
  3. the three Referenced fields
  4. the DR collects the link's prefixes
  5. what RFC 5340 section 4.5.3 still says

basics

~20 s

RFC 5340 made router- and network-LSAs pure topology and moved every prefix into Intra-Area-Prefix-LSAs that point at a router or transit link. A prefix change then leaves the SPF graph untouched, and the topology LSAs become address-family independent.

solid answer

~50 s

An OSPFv2 router-LSA does two jobs: it lists links to neighbours, the edges of the SPF graph, and stub networks with address and mask, the leaves. Changing any address re-originates it, and RFC 2328 says a changed router- or network-LSA forces the whole routing table to be recalculated. RFC 5340 splits the jobs. Router-LSAs (`0x2001`) and network-LSAs (`0x2002`) carry topology only; the **Intra-Area-Prefix-LSA** (`0x2009`) carries prefixes with metrics, and its `Referenced LS Type`, `Referenced Link State ID` and `Referenced Advertising Router` attach them to a router or to a transit link, whose prefixes the DR advertises. A prefix change now re-originates only that LSA, so the Dijkstra graph is unchanged and an implementation can re-attach prefixes without re-running Dijkstra. RFC 5340 itself still lists this LSA as triggering a full recalculation; the saving is an optimisation the split makes possible.

code

pseudocode · 15 lines
pseudocode
# stage 1: graph from router-LSAs (0x2001) and network-LSAs (0x2002) only
dist = dijkstra(vertices = routers + transitLinks)

# stage 2: hang prefixes on the tree
for lsa in area.intraAreaPrefixLSAs:            # LS type 0x2009
    v = vertex(lsa.referencedLsType,
               lsa.referencedLinkStateId,
               lsa.referencedAdvertisingRouter)
    if v not in dist: continue                  # anchor unreachable
    for p in lsa.prefixes:
        if p.options.NU: continue               # excluded from unicast
        cost = dist[v] + p.metric
        install(p.prefix, cost, nextHops(v))

# a prefix-only change alters stage 2 input; stage 1 input is unchanged

go deeper

for a junior

Recall that OSPFv3 router-LSAs and network-LSAs describe topology only, and that prefixes travel in a separate Intra-Area-Prefix-LSA.

for a middle

Explain how an Intra-Area-Prefix-LSA points at a router-LSA or a network-LSA through its Referenced fields, and that the DR advertises a transit link's prefixes.

for a senior

Explain the SPF consequence precisely: the graph is untouched by prefix changes, so prefix-only recalculation becomes possible, while RFC 5340 itself still specifies a full recalculation.

for a principal

Relate the split to design choices it enables: address families on one topology, prefix churn isolated from topology churn, and what that means for convergence and LSA size budgets.

## Two jobs in one OSPFv2 LSA OSPF's route computation, in both versions, has **two stages**. First Dijkstra builds a shortest-path tree whose vertices are **routers** and **transit networks** (multi-access links with a Designated Router). Then the **stub networks**, prefixes that lead nowhere further, are hung on that tree as leaves, each costing the distance to its router plus its own metric. In OSPFv2 (RFC 2328) one LSA feeds both stages. A **router-LSA** lists the router's point-to-point and transit links, the graph's edges, alongside its stub networks as address-and-mask pairs. A **network-LSA** names a transit network by the DR's interface address and carries the network's mask. Addresses and topology are welded together, so: - adding a loopback or a stub prefix re-originates the router-LSA; - RFC 2328 section 13.2 says that when a router-LSA or network-LSA changes, *the entire routing table must be recalculated*, starting with the shortest-path calculation for every area; - the router-LSA grows with every prefix the router owns. ## What RFC 5340 did OSPFv3 removes all addressing from router-LSAs and network-LSAs. They now describe only the graph, and new LSAs carry the addresses. | LSA | LS type | Flooding scope | Carries | |---|---|---|---| | Router-LSA | `0x2001` | area | the router's links to neighbours and transit links: topology only | | Network-LSA | `0x2002` | area | the routers attached to a transit link: topology only | | Intra-Area-Prefix-LSA | `0x2009` | area | IPv6 prefixes, each with a metric, tied to one router or one transit link | | Link-LSA | `0x0008` | link | a router's link-local address and the prefixes on that link | An Intra-Area-Prefix-LSA names its anchor with three fields: `Referenced LS Type`, `Referenced Link State ID` and `Referenced Advertising Router`. 1. **A router's own prefixes** (stub links, loopbacks, attached hosts): the router references its own router-LSA (`0x2001`, Link State ID `0`, its own Router ID). A stub link's prefixes carry that interface's output cost as their metric; the addresses of a looped-back interface go in as `/128` entries with the `LA-bit` set and metric `0`. 2. **A transit link's prefixes**: the link's **Designated Router** references the link's network-LSA (`0x2002`, its own Interface ID, its own Router ID). It copies the prefixes from the Link-LSAs of the routers fully adjacent to it, merges duplicates, leaves out link-local addresses, and sets every metric to `0`. ## How the computation uses them The Dijkstra stage is identical to OSPFv2's; RFC 5340 says the graph is the same and simply drops the step that read stub links from router-LSAs. In the second stage the router walks the area's Intra-Area-Prefix-LSAs. Each prefix costs the referenced vertex's distance plus the prefix's metric. A prefix whose `NU-bit` ("no unicast") is set is skipped. ## What the split buys - **A stable graph.** A prefix change re-originates only an Intra-Area-Prefix-LSA; router-LSAs and network-LSAs do not change, so the shortest-path tree is the same. An implementation can recompute just the prefix stage instead of re-running Dijkstra. - **Smaller topology LSAs.** A router with hundreds of prefixes no longer floods them inside the LSA that describes its adjacencies. - **Protocol independence.** With no addresses in them, router- and network-LSAs serve any address family. RFC 5838 relies on this to carry IPv4 in OSPFv3 without new LSA types. - **Local information stays local.** The link-local addresses used only for next hops live in Link-LSAs and are never flooded across the area. ## What the RFC does and does not promise The split *enables* a cheaper recalculation; it does not mandate one. RFC 5340 section 4.5.3 still lists router-LSAs, network-LSAs, Intra-Area-Prefix-LSAs **and** Link-LSAs among the types whose change recalculates the entire routing table. Section 4.8.1 then allows any other algorithm or optimisation provided it produces an identical shortest-path tree. Prefix-only recalculation is that kind of optimisation: an implementation's choice that the split makes safe, not a protocol rule. An answer claiming that "OSPFv3 never runs a full SPF when a prefix changes" overstates the specification. ## Mistakes that show up in interviews - Saying the router-LSA still lists prefixes, only in 128-bit form. - Confusing the Intra-Area-Prefix-LSA with the Inter-Area-Prefix-LSA (`0x2003`), the renamed type 3 summary-LSA that an area border router originates. - Saying each router on a broadcast link advertises the link's prefix area-wide; the DR does it once, on the link's behalf. - Expecting the Link-LSA to reach the rest of the area; it never leaves its link.

  • On an OSPFv3 broadcast link, which router advertises the link's prefixes to the area, and where does it get them?
    The Designated Router. It originates an Intra-Area-Prefix-LSA whose Referenced LS Type is `0x2002`, Referenced Link State ID is its own Interface ID on the link and Referenced Advertising Router is its own Router ID, pointing at the network-LSA. It copies prefixes from the Link-LSAs of routers fully adjacent to it, merges duplicates, omits link-local addresses and sets each metric to 0.
  • An OSPFv3 router may originate several router-LSAs in one area. How does SPF treat them?
    As one. RFC 5340 lets a router spread its interface descriptions over several router-LSAs, told apart by Link State ID, and requires every receiver to process all router-LSAs from that Router ID as fragments of a single large router-LSA. The Options field and the router-type bits are taken from the fragment with the smallest Link State ID.

A city keeps one street map and a separate directory saying which shops sit at which junction. Opening a shop updates the directory, not the map, so anyone who has already worked out the shortest routes between junctions only needs to look the shop up.

saying these in an interview costs you the question

  • OSPFv3 router-LSAs still list the router's IPv6 prefixes, just in 128-bit form.
  • RFC 5340 guarantees that a prefix change never triggers a full SPF.
  • Intra-Area-Prefix-LSAs are flooded across the whole AS like external routes.
  • Every router on a broadcast link advertises the link's prefix area-wide in its router-LSA.
  • The Intra-Area-Prefix-LSA is the OSPFv3 name for the type 3 summary-LSA.