So, part of my recent push to get mDNS working in my environment revolves around wanting to try more things with IPv6, which I "recently" turned on in my environment. However my first tests with a netbsd-10 host running on bare metal, i.e. with a real physical ethernet interface, have been less than stellar. I've been running IPv6 on the router and with various other devices on the network without problems. These include my macOS systems, iPhones, android phones, Linux laptops, etc. Everything seems to just work. My desktop has a manually configured static and private IPv4 address with IPv6 configured automatically on the ethernet. I'm not sure what macos uses as a DHCP client. Initially I tried just using the auto-assigned IPv6 link-local address, and that "worked", but I had to use ip6addrctl_policy="ipv4_prefer" to get X11 clients on that machine to be able to reliably authenticate to the X11 server running on my macos desktop (XQuartz). This seems to be due to the fact that in combination with nsswitch.conf enabling multicast_dns for hosts, mDNS will return the IPv6 address for the server and the .Xauthority entry for that same hostname then doesn't match. However after I enabled "dhcpcd -6" on the ethernet on this netbsd-10 host to get a global address assigned, things have been a bit wobbly. I've kept the ipv4_prefer policy, but still even the likes of rshd get foiled and don't work: Nov 15 21:17:32 once inetd[10044]: connection from fe80::1030:c7e5:ac6d:b5ce%bge0(fe80::1030:c7e5:ac6d:b5ce%bge0), service shell (tcp6) Nov 15 21:17:32 once rshd[10044]: can't get stderr port: Can't assign requested address The internets aren't very helpful about that failure, though others have seen it in various contexts it seems. In looking for the cause of the rsh failure I also noted that dhcpcd is doing the following every 10 seconds: Nov 15 21:17:37 once dhcpcd[465]: bge0: requesting DHCPv6 information Rumours on the internets are that a newer version of dhcpcd than is in netbsd-10 might avoid this, but the rumours also suggest that the cause is some misconfiguration of IPv6 in the local network, possibly having to do with too-frequent route advertisements or some such. However I'm not savvy enough with IPv6 to even begin to guess what the problem could be, especially since everything other than NetBSD seems to be working OK. For the record my router and firewall is a Netgear ORBI RBR50. It's not so new any more and so maybe it's not doing something right. There's not much to configure on it though. My ISP has been providing IPv6 globally routed addresses for some time now. Also, after my apple-tv rebooted (after updating to tvOS 26), dhcpcd assigned another private net address to the interface (in fc00::/7, i.e. with an fd8d prefix). That seems odd. I didn't know the apple-tv could be running a DHCP server too! My macos desktop also has an address in this same fd8d prefix, and it's listed as "autoconf secured". The macos ifconfig(8) doesn't say what "secured" means. Tomorrow I might try my -current "daily" machine, but it's a domU running with an IPv4-only dom0 under it and I'm not sure if the bridge(6) and xvif(4) interfaces will be transparent to IPv6 traffic or not. The netbsd-10 box is my only bare-metal machine currently that I want to try IPv6 on, though I could probably bring a Pi and/or Soekris, etc. box online soon too. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpx0GMeQ6uGr.pgp
Description: OpenPGP Digital Signature