Re: Is IPv6 nexthop supported?

On Mon, Mar 30, 2026 at 12:37:40AM +0100, Polarian wrote:
> Hey,
>
> Background:
>
> I have a FreeBSD server behind an OpenBSD router. I have a bunch of
> IPv4 addresses but using ARP would require me to lose a few, and
> as its a /29 this would not be ideal. FreeBSD does support IPv6 nexthop,
> and I have had others tell me they use it, and from debugging it doesn't
> seem FreeBSD is the issue here.
>
> IPv4 only way of doing it, that being using a /31 from RFC 1918 to
> route the public IP I have heard works fine on Linux, as you have
> address priority (first address is used for the from header). Within
> FreeBSD this does not exist, and no matter what I tried, the from
> header will always be the /31 address and thus be dropped as its not
> routable.
>
> IPv6 nexthop is the more elegant solution, hop the packet over IPv6 LL
> call it a day.
>
> What happens:
>
> So to test I am pinging google.com from the FreeBSD server (IPv4), DNS
> is done over IPv6 so resolution works fine. Packet does hit the vlan
> interface the server is on router side, but then is dropped. No packet
> out on the wan interface (despite it being the default route) and no
> other routes which would match the packet.
>
> It is not being blocked by pf, confirmed via tcpdump pflog interface.
>
> Router has no route to the IPv4 address either.
>
> There is a real possibility I just configured it wrong, in which case I
> am happy to provide logs/configs, but I also have a feeling that this
> is just not supported on OpenBSD, so hence before I smash my head
> against the table, I thought it would be wise to ask.
>
> If anyone has configured this themself on OpenBSD, please do let me
> know. I see nothing in route(8), and any attempt to mix IPv4 and IPv6
> addresses for the inet routing table throws an error. Which is why I
> suspect this behaviour is just unsupported. In which case, the only
> possible solution remaining is 1:1 NAT.

OpenBSD does not support to use a IPv6 nexthop for IPv4 routes at the
moment. It is something I want to fix at some point but it is not high on
my todo list. You can inject routes like this into the kernel but they do
not work because the way ifp_output is called makes too many assumptions.

--
:wq Claudio