On 2026-06-11, Geoff Steckel <[email protected]> wrote: >> if you want to specify them, I'm pretty sure you'll need DHCPv6, which >> is more of a pain to configure, as the default on most client devices is >> to use some form of SLAAC (either the original form based on MAC, or >> temporary addresses, or SOII) - there is no support for this in OpenBSD >> base (only for DHCPv6-PD, which is different, as a client; nothing for >> aerver side). ... > DHCP6 and SLAAC seem to fight. ULAs? (see below). > Right now I run dhcp6leased(8).
dhcp6leased is *only* for DHCPv6-PD, which is normally run on a router to fetch prefixes from an upstream (ISP etc) and use them to configure downstream interfaces (facing clients). But only the prefixes. For the host part of the addresses on those downstream interfaces, either the clients use SLAAC, or you run DHCPv6 (not -PD) to fetch addresses. dhcp6leased does not support (non-PD) DHCPv6. [Android is starting to use DHCPv6-PD to fetch multiple prefixes so that where there are downstream clients on connection sharing, or if it uses separate addresses for different software (i.e. containers) it does not need to deal with address resolution negotiations with upstream for all of those various addresses. But this is not the standard use case for PD] > It always assigns ::1 to the router interface. > When I notice IPv6 doesn't work I poke dhcp6leased then > manually reconfigure the rest of the router and all the clients > > Superficial scanning of slaacd(8) code suggests setting > -soii and -temporary then autoconf6on an interface > after dhcp6leased finishes negotiating might preserve low order bits. > It's a surprise. > I'll set up spare systems and try this. > > I saw comments about "64 bits of host address". > That could cause problems with a /56. AFAIK all of the IPv6 address configuration methods are based around /64 for networks containing end hosts. Where larger prefixes are used (e.g. in PD) they're for splitting up and allocating /64s to downstream networks. > I didn't look to see what it would do if it found addresses > e.g. ULA already configured. > > dhcp6leased(8) doesn't set a default IPv6 route using > my configuration. Manually setting a default route works. > I can investigate further if anyone asks (verbose logging etc.) > I'll scan the source but I don't know if I'll see > anything useful. You need to forget quite a bit of how v4 DHCP works as it is different in v6 land. DHCPv6 and DHCPv6-PD are _not for setting default routes_. Things start with router advertisements. The default route comes from there, as does the optional M flag to tell the client to use DHCPv6 rather than the default (SLAAC). You will need to use external software, e.g. dhcpcd, to handle this on OpenBSD. It is not supported in base. > Handling global configuration changes automatically when > an IPv6 prefix changes is a separate problem. > A grotesque solution would be to wrap tcpdump(8) to monitor > RA messages or read route(9) to trigger a monstrous script. > > ULAs seem to cause source address choice to do unexpected things. > Host with global & local addresses sending to a local address: > Source address used is global. Perhaps harmless? > Perhaps a configuration error on my part? > An issue to investigate. AFAIK that is not how the address selection is supposed to work by default, but it is a fairly complicated mechanism and I don't remember all the details, that might have been something controlled by local policy on OS which support that. See RFC 6724 for more. Also see RFC 7084 which also makes the suggestion of ULA for this type of situation where there are multiple local subnets. > I use link level addresses for local servers (hack). That usually works too of course as long as you don't need to reach outside the subnet and don't want to handle name resolution by DNS. However with some software it can be difficult or impossible to actual enter a link scoped address.
