Sanity check on my IPv6 settings (/56 PD + DHCP6 enabled)
-
Then try testing with http://ipv6-test.com/
-
@luckman212 said in Sanity check on my IPv6 settings (/56 PD + DHCP6 enabled):
RA is enabled on the LAN and set to Assisted mode. This is what I have been told is most compatible with all types of devices (Windows, Android, iOS, Mac etc). Have not had any issues, although my Macs get two IPv6's, one "secured" and one "temporary". I assume the reason is one is via SLAAC and one is via DHCP6, although I haven't confirmed this and it doesn't seem to harm anything:
I don't have any Macs to compare to, but on a Windows PC, you will see 3 ip6s. One from DHCP, one from SLAAC, and a temporary one. The temporary one is for privacy and is the one that will be the source address from the PC and changes. So like I said, I don't know Macs, so I am not sure if they are set up to use DHCP or not. My iphones get three addresses like the PC's do if DHCP is working.
Now that Windows 10 supports RDNSS I finally decided I didn't need DHCPv6 anymore, so I disabled it and now I use RA set to UnManaged.
-
@isaacfl Thanks for taking a look. Yes I have a rule to allow ICMP there, forgot to mention that. Mine is more permissive- just a blanket "allow all" if you will. Your setup looks more precise, might try to adapt to it.
-
@luckman212 said in Sanity check on my IPv6 settings (/56 PD + DHCP6 enabled):
@isaacfl Thanks for taking a look. Yes I have a rule to allow ICMP there, forgot to mention that. Mine is more permissive- just a blanket "allow all" if you will. Your setup looks more precise, might try to adapt to it.
I think you are ok, just to let all icmp thru. I did that way, for a long time, but recently have been playing with restricting it more.
If you enable logging of the icmp traffic you will see that there isn't that much. Nothing compared to all of the ipv4 port scanning on the WAN.
-
@luckman212 said in Sanity check on my IPv6 settings (/56 PD + DHCP6 enabled):
@isaacfl Thanks for taking a look. Yes I have a rule to allow ICMP there, forgot to mention that. Mine is more permissive- just a blanket "allow all" if you will.
I run the same way, and have for the past 10+ years of IPv6 use.
-
I've been doing some more experimenting, and it seems that when setting the LAN to "Track Interface(WAN)" that it gets assigned an IP in a /64 completely different from (and outside of) the range of the delegated /56. So, the entire /56 is available for downstream sub-routers. No need to omit the first Prefix-ID it seems. I have adjusted my settings and re-tested, everything still seems to work.
Basically the only thing I changed was the Prefix Delegation Range now encompasses the full range of the /56:
2604:2000:xxxx:4400:: --> 2604:2000:xxxx:44f0::
Also, in mucking around I found it can be useful to call on the
gen_subnetv6
andgen_subnetv6_max
PHP functions from the developer shell (opt12). E.g.pfSense shell: require_once('util.inc'); pfSense shell: $ip='2604:2000:ee00:ff00:284c:a2ff:a83b:334c'; pfSense shell: $sn=67; pfSense shell: printf("%s%s\n", 'subnet base: ', gen_subnetv6($ip, $sn)); pfSense shell: printf("%s%s\n", ' max: ', gen_subnetv6_max($ip, $sn)); pfSense shell: exec subnet base: 2604:2000:ee00:ff00:2000:: max: 2604:2000:ee00:ff00:3fff:ffff:ffff:ffff
-
@luckman212 said in Sanity check on my IPv6 settings (/56 PD + DHCP6 enabled):
when setting the LAN to "Track Interface(WAN)" that it gets assigned an IP in a /64 completely different from (and outside of) the range of the delegated /56
That doesn't make a lot of sense. What routed subnet does LAN get assigned from?
-
@derelict said in Sanity check on my IPv6 settings (/56 PD + DHCP6 enabled):
That doesn't make a lot of sense. What routed subnet does LAN get assigned from?
Thanks @Derelict—I'm listing out my (partially masked) IPs below. To be honest, I'm not sure where the
2604:2000:f10f:ce00::/64
subnet is coming from. The primary router's LAN is set to Track Interface(WAN) but it seems like this IP is arriving via SLAAC or something. Not sure how to capture/trace that conversation (tcpdump?) but it's not showing up inradvdump
.Here's what I have currently:
(primary router)
WAN: 2604:2000:ffc0:4:29da:xxxx:xxxx:xxxx/128 LAN(track): 2604:2000:f10f:ce00:2xx:xxxx:xxxxx:e9da/64 /56 via PD: 2604:2000:f120:4400::/56 DHCP6 server on this router is set to offer 16 /60s sliced up from the /56
(sub-router)
WAN: 2604:2000:f10f:ce00:2xx:xxxx:xxxx:55d0/64 (in LAN subnet of above) LAN(track): 2604:2000:f120:44f0:2xx:xxxx:xxxx:55cf/64 (in last /60 from primary router's DHCP6-PD pool)
radvdump
shows my Cable modem advertising these four /64s:2604:2000:700:4::/64 2604:2000:400:4::/64 2604:2000:c00:4::/64 2604:2000:ffc0:4::/64 <-- the one chosen by my primary WAN (random?)
-
SLAAC cannot delegate a prefix. A tracked interface cannot get a /64 from anything given by SLAAC. It has to be DHCP6.
What does your ISP have to say about what they are provisioning there?
-
The ISP is Spectrum/TimeWarner. I'll call them tomorrow, but you don't get to talk to engineers, just call center people. Most of them can't even spell IPv6, much less tell you anything about it.
Another odd thing, I rebooted pfSense and then checked the DHCP logs to see if I could confirm the /56 that was being handed out. I didn't see anything in the log at all for dhcp6 (yes, there was stuff in there before...) :
# clog /var/log/dhcpd.log | grep dhcp6 # <------ ¯\_(ツ)_/¯
radvdump
shows that the /64s being offered there have valid lifetimes ofinfinity
:prefix 2604:2000:ffc0:4::/64 { AdvValidLifetime infinity; # (0xffffffff) AdvPreferredLifetime infinity; # (0xffffffff) AdvOnLink on; AdvAutonomous off; AdvRouterAddr off; }; # End of prefix definition
So maybe pfSense is caching this and just re-using it without triggering dhcp6c at all? I know it's not in config.xml so maybe on the filesystem somewhere? I have to look at the code to see if this is what's actually happening.
I'll try to do some more packet captures as well.