Re: IPv6 routing, Verizon FiOS, dhcpcd

Apologies for top-post, but the earlier retained below is little more than
trimmed history. I wanted to come back to this for advice.  What I have done
to solve (aka work around) this problem for myself is two changes in
/usr/local/etc/rc.d/dhcpcd:

——8<——8<——8<——8<——8<——
--- dhcpcd.orig 2024-10-13 12:22:44.181922000 -0400
+++ dhcpcd 2025-10-06 13:41:14.523012000 -0400
@@ -1,6 +1,7 @@
 #!/bin/sh
 # PROVIDE: dhclient dhcpcd
+# REQUIRE: netif
 # KEYWORD: nojailvnet
 #
@@ -29,6 +30,23 @@
 {
  # dhcpcd may need local binaries
  export PATH=${PATH}:/usr/local/sbin:/usr/local/bin
+}
+
+start_postcmd="dhcpcd_pause"
+dhcpcd_pause()
+{
+	boottime=`sysctl -n kern.boottime | sed -e 's/.*sec = \([0-9]*\),.*/\1/'`
+	now=`date +%s`
+	# When running at boot, it'll take a while to initially set up the
+	# interfaces such that the addresses et al can be bound,  I don't
+	# know why, but in the normal case if I don't wait here, local_unbound
+	# cannot bind port 53 on one or more of the addresses.
+	if [ `expr $now - $boottime` -lt 90 ]; then
+ 		stdbuf -o 0 echo "${name} waiting for addresses to stabilize ... "
+	 	sleep 2
+ 		echo "done"
+	fi
+
 }
   load_rc_config $name
——8<——8<——8<——8<——

Part 1 is what avoids the problem I was originally seeing.  If I delay
dhcpcd starting until after the interfaces are all online, it is able
to successfully talk with the next-hop router.  I still do not know why
it is failing to reach the IPv6 next-hop when it is, and why starting
dhcpcd later avoids the problem.  Any thoughts welcome.
Part 2 above is for the problem I mentioned in a second email about
interface renaming.  It turns out that if local_unbound tries to bind
to the address that dhcpcd has _just_ shoved onto the interface, it
will fail.  The above delay avoids this problem.

The problem, of course, is that I’ve changed dhcpcd to run _after_ netif,
which is not a general solution.  For anyone using dhcpcd to do it’s normal
job of obtaining addresses, it needs to run before or as part of netif.
So, so that I don’t need to maintain my own separate version of this
that is unusable upstream, what can I do to figure out why starting
dhcpcd later (after IPv4 is fully operational or something else in netif),
is required to avoid the problem?

Thanks.

           - Chris

> On 6 Oct 2025, at 13:59, Chris Ross <[email protected]> wrote:
> 
> […] What I am _not_ seeing in tcpdump is 
> neighbor advertisements in response to my NS’s.  At least, when
> the problem is occurring.  I can wait for hours, and I never get
> an NA for the router I’m NS’ing for.
> 
> I see now that in my test where I delayed dhcpcd startup, I do get
> NS back, so that makes sense.  But I can’t imagine how when I start
> dhcpcd affects whether or not Verizon responds to my NS.
> 
>> Does this act the same with another DHCPv6 client like KAME dhcp6c instead of using dhcpcd?
> 
> I have not tested others.  Again, I don’t think it’s a DHCP thing,
> The DHCP part is actually working.  It’s that something else is
> happening at an addressing level.