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@ipng.ch>
PBVP1-RIPE https://ipng.ch/