Re: IPv6 networking problems in 14.3

From: Chris Ross <cross+freebsd_at_distal.com>
Date: Sun, 14 Sep 2025 16:19:22 UTC

> On Sep 14, 2025, at 08:27, Karl Denninger <karl@denninger.net> wrote:
> That gateway isn't by any chance running out of RAM such as on nanobsd (e.g. /var is volatile) is it?


No.  Full fledged machine here.

% df -h /var
Filesystem            Size    Used   Avail Capacity  Mounted on
zroot/ROOT/default    1.4T    7.3G    1.4T     1%    /
% top | head
last pid: 41577;  load averages:  0.00,  0.01,  0.00  up 37+03:40:12    12:11:35
44 processes:  1 running, 43 sleeping
CPU:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
Mem: 30M Active, 639M Inact, 5741M Wired, 136K Buf, 118G Free
ARC: 2464M Total, 1139M MFU, 708M MRU, 723K Anon, 25M Header, 588M Other
     1442M Compressed, 3493M Uncompressed, 2.42:1 Ratio
Swap: 8192M Total, 8192M Free

> If so the duid is non-fixed and some ISPs will have a hiss-fit in that they "marry" the MAC on your end to the MAC on the ONT along with the duid and use that internally. If the duid changes but the MAC does not it will not arp and you're hosed as their end has no internal map back to your gateway thus you don't get the advertisements (and in some cases no delegation either!) and it doesn't come up.
> I also have "noarp" in my config which otherwise made the ISP's gear upset. In addition I have made sure the duid doesn't change (try "duid ll" which will generate one that won't so long as the interface it is applied to doesn't) and/or move /var/db/dhcpcd to something that can be sync'd (e.g. symlink it to /usr/local/etc/db/dhcpcd and then after the first boot sync that) so the duid file gets restored on a restart.
> I ran into this with my fiber here; the former cable company did not care if all this was volatile on a restart however the fiber firm did it was a load of fun to get someone on the phone who actually could figure out *why* their system got mad and wouldn't reconnect. In my case their end would return an IPv4 address and function but would not come back up on IPv6 unless they cleared their internal tables manually.

Thanks for the ideas.  I’m 95% sure my duid/MAC are static.  And, unless that would’ve changed between 14.1 and 14.3, I wouldn’t expect that to be a problem.  I certainly can tell with every reboot that I have the same address.  Let me see if my dhcpcd.log tells me what it used to be...
No, looks like I can confirm the same /56 was delegated before as now, which suggests it’s the same, but doesn’t literally record my IPv6 LL, DUID, or MAC. 

So I think that’s not my problem.  It’s not the ISP.  I can try to switch back to 14.1, I’ll research whether I can do that via ZFS snapshots without it being an act of no return.  Google will tell me.  Otherwise, I may try booting a 14.1 kernel and see what that does.  Might break things with a 14.3 user land, but easy to try.

- Chris