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<[email protected]>
PBVP1-RIPEhttps://ipng.ch/
