OSPF for IPv4 over IPv6 only?

[Pim van Pelt]

Hoi Ondrej,

On 02.04.2024 16:40, Ondrej Zajicek via Bird-users wrote:
> Although one could have option that forces it to interpret as IPv6, i
> would prefer to have 'extended next hop' option that allows to accept
> both IPv4 and IPv6 next hops in Link-LSA.
Did you mean that:
1) under normal circumstances, an ipv4 channel with an ipv6 ospfv3 
adjacency, will respect RFC5838 and overload the link-lsa with the ipv4 
address;
2) when `extended next hop` is active on the interface, an ipv4 channel 
with ipv6 ospfv3 adjacency, will use the ipv6 nexthop in the link-lsa?

If so, (2) will make Bird break interoperability with any other RFC5838 
neighbor.

Is an alternative perhaps, to make Bird choose the message neighbor as 
nexthop, and ignore the link-lsa value when `extended next hop` is set? 
Or is that gross?

Example: if neighbor fe80:foo::1234/64 sent the LSA with nexthop as 
c0000201.00* (192.0.2.1), AND `extended next hop` is set AND the 
interface doesn't have an IPv4 address, only then do we ignore the 
link-lsa but use fe80:foo::1234%iface instead.

Incidentally, if we decide to merge the babel patch I offered, we can 
further create analogous behavior by allowing `extended next hop always` 
which would use the message neighbor address even if an IPv4 address is 
present.

ps - even with IPv4 on the interface and RFC5838 as it was intended, I 
still don't see Bird emit the learned routes to the kernel (see my 
message to Benoit on 30.03.2024, 15:50); so I think even setting 
extended next hop aside, I cannot confirm that OSPFv3 with ipv4 channel 
works in that configuration.

groet,
Pim

-- 
Pim van Pelt<pim at ipng.ch>
PBVP1-RIPEhttps://ipng.ch/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20240402/08ed10c2/attachment.htm>