Re: IPv6 routing, Verizon FiOS, dhcpcd

When initially getting IPv6 working a year or more ago, I tried multiple clients
and was first able to get dhcpcd working, with Roy’s help.  I do have dhcp6
installed, and have a config file for it, but I presume not one that works.

I’ll ping you off-list and share that, then later when the internet can be down
for a while give it a try again to see.  I’m happy to give an alternate client
a try for helping narrow down the problem.

Thanks.

-Chris

> On 4 Nov 2025, at 15:14, Tom Pusateri <pusateri@keehole.org> wrote:
> 
> Does the same problem occur with KAME DHCP client and if so, does the same delay fix the problem at boot? I use the KAME dhcp6 client still (dhcp6-20080615) and it doesn’t seem to have this problem for me but I am using a different upstream provider.
> 
> It sounds like dhcpcd is not handling dynamic interfaces correctly.
> 
> Tom
> 
>> On Nov 4, 2025, at 2:48 PM, Chris Ross <cross+freebsd@distal.com> wrote:
>> 
>> 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 <cross+freebsd@distal.com> 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.
>> 
>> 
>> 
>> 
> 
>