Verizon Fios and IPV6, Which Settings Work?
-
@jmpalacios said in Verizon Fios and IPV6, Which Settings Work?:
I think the only other thing I did, that probably deviates from the general guidance here, is setting the DHCP6 DUID to "DUID-LL: Based on Link-layer Address" in System -> Advanced -> Networking -> IPv6 Options, using my WAN's MAC address (with my WAN interface being the one connected directly to the FIOS ONT).
I agree, I've had to set this as well, although I think I used DUID-LLT instead. In fact I've found that the DUID needs to be updated for IPv6 every time the WAN interface MAC address changes (for instance by changing the WAN interface to a different network port on the firewall), otherwise no new IPv6 prefix would be assigned.
-
@tman222 Well, if I'm not mistaken, the intention is precisely for the prefix to change as little as possible, hence my use of a fixed identifier.
Or am I misunderstanding the purpose of DUID, and/or the way it should be used?
-
@jmpalacios said in Verizon Fios and IPV6, Which Settings Work?:
Well, if I'm not mistaken, the intention is precisely for the prefix to change as little as possible, hence my use of a fixed identifier
That's my understanding too.
-
@JKnott Well, in that case, using a time-based component would cause it to change every time it's renewed. I can of course see several cases in which that would be desirable, but my use-case is not one of those, hence leaving out the time-based component from the DUID.
-
Just wanted to shout out to all those on this thread. I have IPv6 working over FiOS in NYC now with my pfsense CE 2.6.0 setup. Now to migrate my rules to v6.
-
I recently upgraded to Verizon Fios 2Gbit service and it looks like I lost IPv6 capability in the process. The settings described in this thread had been working fine on the prior 1Gbit service, but with the new service I'm unable to get a IPv6 prefix delegated to me (using the same settings). Enabling debug mode on dhcpv6 I see the solicit (RS) going out, but unfortunately no advertisements (RA) follow. Does anyone with the 2Gbit Fios service have IPv6 working for them? The service is still relatively new so perhaps that capability (IPv6) is not yet enabled and will be made available later on. Thanks in advance.
-
@MikeV7896 Just want to say thank you,followed your settings and it works.
-
M madbrain referenced this topic on
-
Hello Mike, 2025 I used your posted settings and cannot have ipv6 work on WAN and one single WIFIVLAN. Do you happen to have any update(s) on this topic?
-
@tman222 Hello from 2025. I just upgraded my FIOS to 2GB from a 1GB circuit where DHCP6 + PD /56 was working fine. Now zero RAs given here too. Searching around here and on Reddit I can't find anyone reporting a working 2G + v6 setup either. So I guess it's back to a tunnel broker for the rest of the year...
-
@luckman212 Hi, I’m having the same issue. Which tunnel are you using? The one I tried was limiting my speed to about 200–400 Mbps, and it feels a bit pointless to have a 2 Gbps connection if the tunnel only gives me a fraction of that. Since majority of the traffic will prefer IPv6 pathway. Thanks.
-
@betapc I haven't set up the tunnel yet, because I ran out of time yesterday. but I'm going to try these 3:
I'll let you know about the results.
I had the same problem years ago (with macOS mostly) where clients were preferring the IPv6 route, so I wrote a Python module for Unbound to strip away AAAA records from DNS responses. This forces IPv4-only but still allows V6 traffic when I specifically target an IPv6 host by address. The script also has an allowlist (config file) of domains to pass AAAA records thru for, since I have some IPv6-only services I deal with.
So far so good on all that. But it's only been 2 days.
-
@luckman212 said in Verizon Fios and IPV6, Which Settings Work?:
@tman222 Hello from 2025. I just upgraded my FIOS to 2GB from a 1GB circuit where DHCP6 + PD /56 was working fine. Now zero RAs given here too. Searching around here and on Reddit I can't find anyone reporting a working 2G + v6 setup either. So I guess it's back to a tunnel broker for the rest of the year...
Hi @luckman212 - thanks for testing and confirming that unfortunately IPv6 still doesn't work yet on the Fios 2Gbit service. I tried getting it work way back in 2023 without success, and was about to try again to see if works now (2 years later), but your report saved me the time. Hopefully it will be implemented before too long. Thanks again.
-
The original settings in this thread worked fine for me a few years ago when Verizon began rolling this out. Then they seemed to roll everything back in late 2023 and I went the whole of 2024 with no ipv6. I noticed this summer that I was seeing ipv6 addresses again and when looking into it, they appeared to have enabled it all again in Jan. of this year. But by the time I noticed over the summer, I had upgraded to the latest pfsense version and also switch over to KeaDHCP server.
I tried using it for an online game and was noticing that I was getting dropouts for 15 minutes about every hour, so I just went back to using ipv4. This weekend I started looking at it more closely and found that every 1 hour 15 minutes, I would lose the ability to use ipv6. These are the entries I would see in my logs. The period from 9:52-10:04, I would have no ipv6 connectivity. IPv4 would renew the leases fine and connectivity there was unaffected.
Oct 12 10:04:40 dhcp6c 55217 dhcp6c Received INFO Oct 12 10:04:39 dhcp6c 55217 Sending Renew Oct 12 10:04:36 dhclient 40170 bound to <redacted ip> -- renewal in 3600 seconds. Oct 12 10:04:36 dhclient 18404 Creating resolv.conf Oct 12 10:04:36 dhclient 17251 RENEW Oct 12 10:04:36 dhclient 40170 DHCPACK from <redacted ip> Oct 12 10:04:36 dhclient 40170 DHCPREQUEST on igb0 to <redacted ip> port 67 Oct 12 09:52:27 kea-dhcp6 21138 WARN [kea-dhcp6.alloc-engine.0x1c3afd017400] ALLOC_ENGINE_V6_ALLOC_FAIL_CLASSES duid=[<redacted>], [no hwaddr info], tid=0x6b0e2c: Failed to allocate an IPv6 address for client with classes: ALL, pool_lan_0, UNKNOWN Oct 12 09:52:27 kea-dhcp6 21138 WARN [kea-dhcp6.alloc-engine.0x1c3afd017400] ALLOC_ENGINE_V6_ALLOC_FAIL_NO_POOLS duid=[<redacted>], [no hwaddr info], tid=0x6b0e2c: no pools were available for the lease allocation Oct 12 09:52:27 kea-dhcp6 21138 WARN [kea-dhcp6.alloc-engine.0x1c3afd017400] ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET duid=[<redacted>], [no hwaddr info], tid=0x6b0e2c: failed to allocate an IPv6 lease in the subnet <redacted ip>::/64, subnet-id 1, shared network (none) Oct 12 09:52:27 kea-dhcp6 21138 WARN [kea-dhcp6.alloc-engine.0x1c3afd016d00] ALLOC_ENGINE_V6_ALLOC_FAIL_CLASSES duid=[<redacted>], [no hwaddr info], tid=0x6b0e2c: Failed to allocate an IPv6 address for client with classes: ALL, pool_lan_0, UNKNOWN Oct 12 09:52:27 kea-dhcp6 21138 WARN [kea-dhcp6.alloc-engine.0x1c3afd016d00] ALLOC_ENGINE_V6_ALLOC_FAIL_NO_POOLS duid=[<redacted>], [no hwaddr info], tid=0x6b0e2c: no pools were available for the lease allocation Oct 12 09:52:27 kea-dhcp6 21138 WARN [kea-dhcp6.alloc-engine.0x1c3afd016d00] ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET duid=[<redacted>], [no hwaddr info], tid=0x6b0e2c: failed to allocate an IPv6 lease in the subnet <redacted ip>::/64, subnet-id 1, shared network (none)After fooling around with various settings and searching online, I came to the conclusion that pfsense's implementation of KeaDHCP did not appear to handle renewals of the prefix delegation. I don't know if that is the right conclusion, but the config that was being generated looked to have hard coded subnet ranges and never used Kea's pd-pools config block.
Ultimately, all I did to "fix" this was to disable the KeaDHCP service on my LAN interface and change the Router Advertisment-->Router Mode from Managed to Assisted and let my clients sort ipv6 themselves instead of having the router do DHCP. I could set it to Stateless but if someone can tell me what I was doing wrong I'll try and set up DHCP6 again.
As I could not find others online having this problem, I assume I did not have the DHCP server configured correctly, but at least for my use case, I don't actually need DHCP6.
Since making that change, my ipv6 dropouts ceased. Also, an unexpected 1.5-2ms reduction in ping time to the target I was using.
Hopefully this helps others who might end up in a similar boat. This and the now lost thread on dslreports.com were tremendous resources for getting this working originally.
