OSPF for IPv4 over IPv6 only?

[Ondrej Zajicek]

On Tue, Apr 02, 2024 at 11:49:21PM +0200, Pim van Pelt via Bird-users wrote:
> Hoi Ondrej,

Hi


> 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?

Yes, if there is no IPv4 address or when forced (like your 'extended next hop
always').


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

Yes, such option will break interoperability, but if you have no IPv4
address on the interface, what address put to Link-LSA anyway?


> 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.

There is an alternative way to get route nexthops, from (Hello packet)
source addresses stored in neighbor structures, indexed by neighbor's
router ID. That is probably what you mean by 'message neighbor'.

We use this for PtP/PtMP links in OSPFv2 and OSPFv3-IPv6. But it is
problematic on multi-access links, where you have adjacency just with
DR/BDR. It cannot be used for NBMA links (as you may have no
communication with other neighbors). On broadcast links, you have at
least Hello exchange with neighbors, but there are still some problematic
cases when multiple interfaces are used to connect to one network.


> 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.

Will check that both.

-- 
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."