# OSPFv3 on Bird Needs IPv6 LLA on the Loopback Interface

DevFeed: [OSPFv3 on Bird Needs IPv6 LLA on the Loopback Interface](<https://devfeed.tech/articles/ospfv3-on-bird-needs-ipv6-lla-on-the-loopback-interface-11115.md>)

Original publisher: [Read original article](<https://blog.ipspace.net/2025/01/bird-ospfv3-ipv6-lla-loopback/>)

Published: 2025-01-07T06:58:00Z

Content type: article

Language: en

Sources: [ipSpace.net blog](<https://devfeed.tech/sources/ipspace-net-blog.md>)

Topics: [networking](<https://devfeed.tech/topics/networking.md>), [Routing (disambiguation)](<https://devfeed.tech/topics/routing.md>), [configuration](<https://devfeed.tech/topics/configuration.md>)

Tags: [ipv6](<https://devfeed.tech/tags/ipv6.md>), [netlab](<https://devfeed.tech/tags/netlab.md>), [ospf](<https://devfeed.tech/tags/ospf.md>), [routing](<https://devfeed.tech/tags/routing.md>), [test](<https://devfeed.tech/tags/test.md>), [tests](<https://devfeed.tech/tags/tests.md>)

## AI overview

The article describes a Bird routing daemon issue affecting OSPFv3 integration tests. Bird ignores an interface without an IPv6 link-local address, including a loopback configured as a stub, so the loopback IPv6 prefix is not advertised. Adding a static link-local address to the loopback interface resolves the tested scenario.

## Source excerpt

Wanted to share this "too weird to believe" SNAFU I found when running integration tests with the Bird routing daemon. It's irrelevant unless you want Bird to advertise the IPv6 prefix configured on the main loopback interface (lo) with OSPFv3. Late last year, I decided to run netlab integration tests with the Bird routing daemon. It passed most baseline netlab OSPFv3 integration tests but failed those that checked the loopback IPv6 prefix advertised by the tested device (test results). Read more ...