Current Best Practices

[JamesFrisch]

I also only need DNS for things I want to access. Well not even then, to be honest. I want to reach my invoices tool, I use the public FQDN, which goes to my proxy. I am just unsure if that proxy should internally use an IPv6 or a hostname to proxy_pass the traffic.

Will take a look at Avahi, at a glance this looks like mDNS. Do you access only local devices or do you have some kind of multicast repeater on OPNsense running?

[Patrick M. Hausen]

Avahi is mDNS. It is "the" open source implementation for that.

To work across VLANs you need a repeater, yes.

In reverse proxying I use IP addresses, but when accessing e.g. an internal UI or for monitoring with Uptime Kuma I use DNS. Manually created in cases where I want IPv6, but that's rare.

Internet --> IPv6 GUA --> Caddy --> e.g. Nextcloud via IPv4.

[meyergru]

What I wanted to hear is:
SLAAC just like IPv4 watches for new DHCP leases.
But just like @meyergru said;

There seems to be no equivalent for /var/dhcpd/var/db/dhcpd6.leases.

Which brings me to my next question.
Should I use DHCPv6 for these VLANs?
I again can't really find any advantages, am I missing something?

By assigning IPv6 with DHCPv6, my client gets a static IP, and this is hopefully also registered in the DNS.
But at the same time, my client gets a static IP anyway, so again, sounds like the same amount of work, but now my proxy is dependent on the DNS.

Is DHCPv6 only really useful, if you don't have a static prefix?

It seems you are finally getting to the same conclusions as me. I said most of this in my first answer and in the article I linked to.

Basically, it goes like this:

1. IPv6 cannot in all cases obtained through DHCPv6, so SLAAC is usually the best way to go. That also works for outbound access. I explained that here.
2. For inbound access and to address devices on your LAN, you would want DNS. But that works only in one of two ways:
a. By obtaining the DNS entry via a DHCPv6 request and registering it - at least, theoretically, because that is supported by neither Kea nor ISC DHCP. Plus, see #1.
b. By putting the DNS name directly into DNS, but that is tedious and does not work for most people because of dynamic IPv6 prefixes, anyway.

And since IPv6 is not even supported by some devices (or services, e.g. on Docker)  at all, you can eliminate all of these problems by just using IPv6 via SLAAC for outbound access and have your internal DNS IPv4-based. Your reverse proxy will take care of the rest, namely to translate from IPv6 on WAN to IPv4 on your LAN. The exception to this rule would be IPv6 services were a reverse proxy is not applicable. In those cases, you have to go with #2b, as Patrick suggested. Otherwise, he obviously takes the same IPv4-based approach as me (talking about "best practice" here).

To put it short: You are making it hard on yourself and try to remedy problems that you create by insisting to try "IPv6 only" without a good reason.

[JamesFrisch]

Thank you Patrick, really appreciate your answers.

Internet --> IPv6 GUA --> Caddy --> e.g. Nextcloud via IPv4.

To play devils advocate here, why not use that static GUA IPv6 instead? Tried that with one of my services, worked great.

It seems you are finally getting to the same conclusions as me.

I am a little bit slow :)

To put it short: You are making it hard on yourself and try to remedy problems that you create by insisting to try "IPv6 only" without a good reason.

That is a fair point. My reason is not technical, but mostly for fun. My switch might be a little bit faster (nanoseconds) using IPv6 for the last part? Who knows? ;)

But what is cool about ditching IPv4 is that you need less stuff. Like a DHCP server. I am currently using ISC. Why not shutting it down, instead of migrating? Here is just one recent learning I got from doing that:

I was wondering why my invoice software shows an update but then times out trying to do that over the webGUI. Turns out it gets the update from Github. And Github is still IPv4 only :)

[Patrick M. Hausen]

To play devils advocate here, why not use that static GUA IPv6 instead? Tried that with one of my services, worked great.

Simple answer: SSL termination and certificate management. It's all in Caddy and all fully automatic.

All my public web services run through that single GUA and a single IPv4 address that way. Of course for e.g. Minecraft I placed the SLAAC GUA of the Minecraft server in its isolated VLAN into the public DNS.

[JamesFrisch]

Gotcha.

I do almost the same. All services point to my dual stack nginx.
I do SSL only on the Proxy and proxy pass http from there. Since the proxy and the service VM are the only two devices in their own VLAN, I don't see a reason why I would use SSL internally.