OSPF for IPv4 over IPv6 only?

[Ondrej Zajicek]

On Fri, Apr 05, 2024 at 04:27:27PM +0200, Pim van Pelt wrote:
> Hoi,
> 
> On 4/5/24 15:23, Ondrej Zajicek wrote:
> > I have almost implemented 'extended next hop' for OSPFv3. But then i
> > pivoted to supporting properly IPv4 loopback nexthop [*]. Now i have
> > doubts about usefulness of 'extended next hop', as any IPv4 router needs
> > at one IPv4 address anyways (at least to be able to send ICMP messages)
> > and there is no need to put IPv4 addresses on links. Are there any good
> > arguments for it?
> In VPP, an interface that does not have an ip4 address, will not allow for
> ip4 traffic to enter it. In other words, there must be an ip4 address on the
> interface before forwarding is turned on.
> I know how to change that behavior in VPP, but it's not a problem in
> practice, because we can set 'unnumbered' interface and borrow an IPv4
> address from another interface, usually a loopback interface with a /32 ip4
> and /128 ip6.
> 
> I think it'd be super cool to use OSPFv3 without IPv4 transit networks and
> just reusing the loopback addresses, like so:
> 
> root at vpp0-2:~# ip -br a
> lo               UNKNOWN        127.0.0.1/8 ::1/128
> loop0            UNKNOWN        192.168.10.2/32 2001:678:d78:200::2/128
> fe80::dcad:ff:fe00:0/64
> e0               UP             192.168.10.2/32 2001:678:d78:200::2/128
> fe80::5054:ff:fef0:1120/64
> e1               UP             192.168.10.2/32 2001:678:d78:200::2/128
> fe80::5054:ff:fef0:1121/64
> *
> *However, up-thread (message of 2024-04-30, 16:04) I had that configuration,
> saw the LSAs but did not see Linux (nor VPP) pick up the routes.

Even if LSAs are here the question is whether OSPF generated such routes
(i.e. whether birdc show route would show them). In order for kernel to
pick them up, OSPF has to generate them and with 'onlink' flag on next
hop.

> My
> suspicion is that your commit will be inert in this scenario, because e0
> already has an IPv4 address, so loopback_addr_used will remain 0.

I think it might help, because even if loopback_addr_used will remain 0,
there is also this change in the patch:

https://gitlab.nic.cz/labs/bird/-/commit/280daed57d061eb1ebc89013637c683fe23465e8#da87cc518d8a6ca24bc804dfc6ad134504731a9c

That for OSPFv3-IPv4 removes next-hop-in-address-range check (and
automatically adds onlink flag), which caused rejection of such next
hops.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
"To err is human -- to blame it on a computer is even more so."