Re: IPv6 routing, Verizon FiOS, dhcpcd

Getting a router advertisement is independent of getting an IA_NA global address for your upstream interface, however, the provider could be filtering your router until it gets a DHCPv6 round trip. 

Use tcpdump to capture the router advertisements on your upstream interface. This will show router advertisements and router solicitations. In my case, they’re sent about every 24 minutes. A router solicitation would trigger one at restart.

# tcpdump -i igc0 -v 'icmp6 and (ip6[40] == 134 or ip6[40] == 133)'
tcpdump: listening on igc0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
23:28:22.673448 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::1 > fe80::7e10:c9ff:fe3d:fb2c: [icmp6 sum ok] ICMP6, router advertisement, length 24
hop limit 64, Flags [managed, other stateful], pref medium, router lifetime 4500s, reachable time 0ms, retrans timer 180000ms
  source link-address option (1), length 8 (1): 00:00:5e:00:01:b7
23:52:34.673680 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::1 > fe80::7e10:c9ff:fe3d:fb2c: [icmp6 sum ok] ICMP6, router advertisement, length 24
hop limit 64, Flags [managed, other stateful], pref medium, router lifetime 4500s, reachable time 0ms, retrans timer 180000ms
  source link-address option (1), length 8 (1): 00:00:5e:00:01:b7
00:14:01.673272 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::1 > fe80::7e10:c9ff:fe3d:fb2c: [icmp6 sum ok] ICMP6, router advertisement, length 24
hop limit 64, Flags [managed, other stateful], pref medium, router lifetime 4500s, reachable time 0ms, retrans timer 180000ms
  source link-address option (1), length 8 (1): 00:00:5e:00:01:b7


See if you have a default route and try pinging the default IPv6 route:

# netstat -6nra|grep default
default                           fe80::1%igc0                  UG             igc0

# ping6 fe80::1%igc0
PING(56=40+8+8 bytes) fe80::7e10:c9ff:fe3d:fb2c%igc0 --> fe80::1%igc0
16 bytes from fe80::1%igc0, icmp_seq=0 hlim=255 time=1.190 ms
16 bytes from fe80::1%igc0, icmp_seq=1 hlim=255 time=2.644 ms
^C

If no ping, see if you have a Mac address for the router:

# ndp -a | grep fe80::1%igc0
fe80::1%igc0                         00:00:5e:00:01:b7   igc0 15s       R R


Does this act the same with another DHCPv6 client like KAME dhcp6c instead of using dhcpcd?

Tom

> On Oct 4, 2025, at 12:46 PM, Chris Ross <cross+freebsd@distal.com> wrote:
> 
> Good day.  This is picking up after a long thread a couple weeks back:
> 
> Subject: IPv6 networking problems in 14.3
> Archive: https://lists.freebsd.org/archives/freebsd-net/2025-September/007532.html
> 
> So following Tom Pusateri’s suggestion, I pulled an old server out of the
> rack, and set it up near the center of the house.  From here, I could
> disconnect everything and plug directly into the ethernet out to the Verizon
> ONT.  I’m running with a simplified rc.conf, and mostly the same dhcpcd.conf
> as my real router.  I am not using pf at all, nor most of the other services
> the router uses.  Just system DHCP from Verizon 'ifconfig_bce1=“SYNCDHCP”'
> and dhcpcd.  (Well, +ssh, +zfs, +ntpd, but…)
> 
> Lots and lots of testing showed me:
> 
> 1. 14.1 and 14.3 seem to act the same
> 2. If dhcpcd starts up before the interface has a link, which it frequently
> does, the Verizon LL router address is never reachable.
> 3. If I delay starting dhcpcd until after IPv4 connectivity is established,
> dhcpcd sets up the same way, but the router LL is reachable, and IPv6
> routing works.
> 
> There are a couple issues here that complicate things.  First, I’m using
> dhcpcd for IPv6 only, which means delaying startup is fine.  But, if
> someone were using it for general networking, that’s clearly a blocker.
> Second, I cannot imagine why starting dhcpcd earlier caused the kernel
> to somehow become unable to reach the ISP v6 LL address for the router.
> If dhcpcd can’t talk to anything, it backs of and tries later.  When it
> tries later, it gets DHCP6 responses, and does what it should do. 
> However, the LL address that it gets from the RA just isn’t reachable.
> “ndp -an” shows it as “(incomplete)” for a second, then not at all.
> 
> So, first, why if dhcpcd starts early does the system get into a state
> where it is unable to reach the advertised IPv6 router?  And that this
> won’t ever fix itself.  (2+ hours tested on test box, days/weeks seen
> on original router)
> 
>                - Chris
>