2 Apr
2024
2 Apr
'24
9:49 p.m.
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-RIPEhttps://ipng.ch/