On Mon, Oct 09, 2017 at 06:31:06PM +0000, lists+m...@ggp2.com wrote: > Hello all - > > I don't feel this warrants a bug report, but nevertheless feel that this > behavior is inconsistent with the way dhclient works. I have a vultr
there is a school of thought that says dhclient should not delay the boot process until it has a lease (or times out after what? 30 seconds?) > server running nsd/OpenBSD 6.2, and I suspect that the move to slaacd > from kernel code in 6.1 is what has broken my nsd config (it fails to > start on boot now). sure, you got lucky before, the kernel did the stateless address auto configuration dance faster and won the race against nsd. slaacd is losing. But if your router solicitations had been delayed nsd might have one the race against the kernel... > > Vultr uses dhcp/autoconf for ipv4/ipv6, and nsd worked perfectly on Uhm, no. vultr *supports* dhcp/autoconf. But they assign a static v4 address and a v6 /64 subnet from which you are free to choose any address(es) you want. They tell you that you get your gateway from router advertisements in v6. > OpenBSD 6.1. In my nsd.conf, I specify the outbound ipv4/ipv6 > addresses, and the idea is that the interface addresses are assigned > before nsd is started. This was the case in oBSD 6.1. However, in 6.2, > it seems that slaacd is assigning the ipv6 address after nsd starts. > This leads to error messages such as: > > nsd[15166]: xfrd: could not bind source address:port to socket: Can't assign > requested address > > I've gotten around this by using the ipv4 address for xfr's, and having > nsd listen on ::1@8053 (unbound has :53) for ipv6 & redirecting with pf. I would suggest to use static IPs for servers as a better work around. Also note that vultr gives you a full /64 v6 subnet, no need to dick around with different port numbers. Of course depends on what you are doing... > > I *think* the proper behavior should be that daemons wait on slaacd to > attempt to solicit/bind first, similar to dhclient. > ah, but it's not the daemons that wait, dhclient is delaying. > I do admit that I've been tinkering with ipv6 a lot lately and twisting > all the knobs, but hopefully this is helpful info as we transition more > ipv6 dominant internet. > -- I'm not entirely sure you are real.
