<div dir="ltr"><div dir="ltr">Hoi Ondrej, Nico, Sebastian,<div><br></div><div>I am revisiting this thread based on the question from Benoit this week (<a href="https://www.mail-archive.com/bird-users@network.cz/msg07961.html">https://www.mail-archive.com/bird-users@network.cz/msg07961.html</a>).</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 30, 2024 at 3:25 PM Ondrej Zajicek <<a href="mailto:santiago@crfreenet.org">santiago@crfreenet.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jan 30, 2024 at 12:20:41PM +0100, Sebastian Hahn wrote:<br>
> Hi Nico,<br>
> <br>
> > On 30. Jan 2024, at 10:32, Nico Schottelius via Bird-users <<a href="mailto:bird-users@network.cz" target="_blank">bird-users@network.cz</a>> wrote:<br>
> > OSPFv3 works fine on IPv6 and when creating two instances, one for IPv6<br>
> > one for IPv4, things look correct. But how does OSFPv3 conceptually work<br>
> > if the interface of the ospf area do not have IPv4 addresses themselves?<br>
> > <br>
> > In the BGP case we can use "extended next hop on;" to use the IPv6<br>
> > nexthop for IPv4, but I did not find a similar setting for OSPF to<br>
> > accept IPv6 nexthops for IGP IPv4 addresses.<br>
> > <br>
> > Is there a way to purely go IPv6 only and still relay stub network IPv4<br>
> > information via an IPv6 only internal area?<br>
> <br>
> I was facing the same issue before, and unfortunately, RFC 5838<br>
> explicitly forbids IPv4 over IPv6 for OSPF.<br></blockquote><div>Sebastian - my interpretation of 5838 is slightly different, and I don't think it expressly forbids xAF nexthops:</div><div>> 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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Well, we could add 'extended next hop' option to override it, even if it<br>
would be non-standard. It is rather small deviation.<br>
<br>
I also thought about 'integrated-OSPFv3', where both IPv4 and IPv6 ranges<br>
are propagated in one instance, but that seems like much larger deviation.<br></blockquote><div>Seeing as OSPFv3 will establish an IPv6 adjacency, and exchange routes, I think that using IPv6 nexthops could be very useful.<br></div><div><div></div></div><div><div>I think adding 'extended next hop on|off|always' would be a pretty wonderful addition.</div><div>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.</div></div><div><br></div><div>groet,</div><div>Pim</div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Pim van Pelt <<a href="mailto:pim@ipng.nl" target="_blank">pim@ipng.nl</a>> <br>PBVP1-RIPE - <a href="http://www.ipng.nl/" target="_blank">http://www.ipng.nl/</a></div></div>