OSPF for IPv4 over IPv6 only?

[Pim van Pelt]

Hoi Ondrej, Nico, Sebastian,

I am revisiting this thread based on the question from Benoit this week (
https://www.mail-archive.com/bird-users@network.cz/msg07961.html).

On Tue, Jan 30, 2024 at 3:25 PM Ondrej Zajicek <santiago at crfreenet.org>
wrote:

> On Tue, Jan 30, 2024 at 12:20:41PM +0100, Sebastian Hahn wrote:
> > Hi Nico,
> >
> > > On 30. Jan 2024, at 10:32, Nico Schottelius via Bird-users <
> bird-users at network.cz> wrote:
> > > OSPFv3 works fine on IPv6 and when creating two instances, one for IPv6
> > > one for IPv4, things look correct. But how does OSFPv3 conceptually
> work
> > > if the interface of the ospf area do not have IPv4 addresses
> themselves?
> > >
> > > In the BGP case we can use "extended next hop on;" to use the IPv6
> > > nexthop for IPv4, but I did not find a similar setting for OSPF to
> > > accept IPv6 nexthops for IGP IPv4 addresses.
> > >
> > > Is there a way to purely go IPv6 only and still relay stub network IPv4
> > > information via an IPv6 only internal area?
> >
> > I was facing the same issue before, and unfortunately, RFC 5838
> > explicitly forbids IPv4 over IPv6 for OSPF.
>
Sebastian - my interpretation of 5838 is slightly different, and I don't
think it expressly forbids xAF nexthops:
> 2.5: Although IPv6 link local addresses could be used as next hops for
IPv4 address families, it is desirable to have IPv4 next-hop addresses.

Well, we could add 'extended next hop' option to override it, even if it
> would be non-standard. It is rather small deviation.
>
> I also thought about 'integrated-OSPFv3', where both IPv4 and IPv6 ranges
> are propagated in one instance, but that seems like much larger deviation.
>
Seeing as OSPFv3 will establish an IPv6 adjacency, and exchange routes, I
think that using IPv6 nexthops could be very useful.
I think adding 'extended next hop on|off|always' would be a pretty
wonderful addition.
It would allow operators to cut down on IPv4 ptp transit networks, and
catch up with Babel (also referenced in this thread as an alternative),
without violating RFC5838.

groet,
Pim
-- 
Pim van Pelt <pim at ipng.nl>
PBVP1-RIPE - http://www.ipng.nl/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20240331/84d8249c/attachment.htm>