It's important to distinguish between stateful and stateless DHCPv6. stateless DHCPv6 is fine. It's just a way for nodes to get dns/ntp/etc. Nodes still select their addresses with SLAAC.

Stateful DHCPv6 is the bad one. It assigns hosts specific addresses.

> the router essentially always knows the MAC address, IP address and hostname of each device.

You can still have this with ipv6 addresses. They easiest way is to use eui64, the original ipv6 addressing scheme where the address is calculated from the subnet + the MAC address of the interface. That way server VMs get deterministic addresses. If you use network-manager you can configure eui64 with the "add-gen-mode=eui64" setting.

In my homelab, I have a few server VMs that use eui64 addressing whereas the end user devices use privacy addresses randomly selected from the subnet.

SLAAC can advertise the DNS server. Why would you call stateful DHCP bad?

> SLAAC can advertise the DNS server.

RFC6106 ? You're right that works. I was just trying to communicate the unobjectionable nature of stateless DHCPv6.

Stateful DHCPv6 is bad because it undermines the concept of hosts selecting their own addresses as needed for privacy, tethering, etc.

The decade old Android issue where Google refuses to implement stateful DCHPv6 provides some good background: https://issuetracker.google.com/issues/36949085#comment53

>Since DHCPv6 is apparently frowned upon by v6 purists, and not all devices on my network support it, that leaves SLAAC.

It's not a dichotomy between DHCPv6 and SLAAC. You can hard-coded addresses too. Since it's your homelab you presumably already know all the devices that will be connected. It's what I do.

You may not even need to hard-code the prefix everywhere. Eg with systemd-networkd you can configure the device as:

    [Network]
    IPv6AcceptRA=yes
    [IPv6AcceptRA]
    Token=static:::1:2:3:4

... which will give that interface the address $prefix::1:2:3:4 based on whatever $prefix was advertised by radvd. So the only place where you'd need to hard-code $prefix is in your DNS server.

>My question then is: is there some standard for the DNS server on the router to somehow know the v6 IPs of the hosts on the network

NDP discovery (`ip -6 neigh show`) will let you know about other IPs (and corresponding MAC addresses) on the link. It won't do anything for matching them up to DNS names.

> Since DHCPv6 is apparently frowned upon by v6 purists, and not all devices on my network support it, that leaves SLAAC.

The main hold out against DHCPv6 is Android:

* https://issuetracker.google.com/issues/36949085

that thread is amazing. Google's stance makes me want to deploy DHCPv6 simply to spite them. I guarantee in 10 years when some Fortune 500 company or top 20 research university IT department, who has no idea about that thread, goes live with a DHCPv6-only IPv6 stack because it's very similar to their IPv4 network, and 30,000 users can't join their Android devices to the campus wifi, this attitude will change

A conference wlan with google engineers attending might be more impactful.

Complains by them? Won't fix (Intended behavior)

I wouldn't be surprised if some corporate networks standardized on iOS / iPhone / iPads for this reason.

I have a similar setup. I wouldn't say that DHCPv6 is frowned upon, it works quite well and is the only way to automatically add client hostnames to the local name server. I use both SLAAC and DHCPv6 mainly because Android refuses to support DHCPv6, but I don't need to refer to my phones by hostname anyway.

I’m in a similar spot as the OP, and one thing that is important to me about knowing the hostnames is that defining (then tracking) a hostname is the only universally-implemented method that lets me scan through the hosts on the network and understand what they all are.

- I’m never going to remember MACs

- Even when IPs are carefully thought out, if something happens to the DHCP server and it needs to be rebuilt, IP no longer tells you anything about what device it is

Whereas hostname/DHCP client name shows up in almost every router UI, is viewable from any *nix machine on the network (when DHCP and DNS work together), and is typically a first-class citizen in the DHCP lease settings themselves. Super handy. As a side bonus: rogue hostnames are immediately obvious, but rogue MACs or IPs require investigation before you know whether they are benign.

The way I handle this on my home network is to advertise a ULA prefix in addition to the one delegated by my ISP. The ULA addresses are not routed. They’re just used for my network. My home DNS server advertises AAAA records using the stable, ULA addresses for those servers I want to advertise. For other machines (like computers, laptops, etc), I rely on mDNS.

In what way is DNS and DHCP tightly coupled? Automatically creating A records for DHCP hosts is not normal in my experience, especially for consumer routers. If some device your using supports this it could work for IPv6 as well as devices will broadcast on the network for routers when using SLAAC I believe.

Many home devices use dnsmasq as their DHCP server and DNS resolver, and it can optionally use hostnames from the DHCP part of its business during resolving DNS too.

The point GP had that it won't work, then DHCPv6 is not used.

There is not really an equivalent for what dnsmasq does.

I ended up with bind and rfc2136 dynamic updates. Not all devices are capable of doing it, but it is what Active Directory does by default.

It isn't really true that DHCP and DNS are coupled, it's just a common feature for power user routers as it's convient.

There are options for IPv6: PFSense, as an example, has "Assisted" RA mode where devices can use SLAAC or DHCPv6, so you have SLAAC for general clients that don't need more (e.g: phones that don't support DHCPv6), but clients that want more can use DHCP to provide specific reserved addresses and DNS names, etc...

Can't answer your main question, but from what I recall, DHCPv6 is kind of necessary anyway. It's the easiest/main way for the client to receive DNS server information, even if default gateway discovery is now down through multicast.

I believe there is another way, but the router has to support it and I forget what it's called.

RA (Router Advertisement) handles announcing the prefix for SLAAC addresses and DNS.

But not other services like NTP, so DHCPv6 is still needed.

Create a DNS name ntp.yourdomain.example.org that points at your internal ntp servers.

Configure your ntp clients to use the name, and maybe add a pool.ntp.org entry or two into your configs.

> Configure your ntp clients to use the name

So how do you do this hands-off, ie without manually changing things on the clients, without DHCPv6?

For NTP, an alternative is letting the LAN devices connect to whatever NTP server they want to, and just NAT'ing outgoing udp/123 to your NTP server.

Well yes, but that's a suboptimal hack.

yes, but RDNSS is a relatively new option (only since 2007 ;) ), so some implementations ignore it.

It's not usual for your router to create A or AAAA records for the hosts connected to it. Look into Multicast DNS.

Maybe not, but it's super convenient and well supported by isc-dhcp-server/bind9. I do it on all my networks.

If I want to connect to something by name then I setup a wireguard connection with a fixed ip. The few things that don’t allow for that all use mdns anyway.