Why does pfsense run dhcpv6 and slaac by default?
-
Why does pfsense run dhcpv6 and slaac by default? Is there any real reason for this since android devices still dont use DHCPv6, and with rddns you can provide dns via slaac.
Is this just an out of the box setting for every use case?
-
Probably because the vast majority of ISPs that offer IPv6 do so via IPv6 prefix delegation which requires DHCPv6. That's really the only thing DHCPv6 is used for in most installs (to handle the prefix delegation as that's a DHCPv6 thing).
Most pfSense IPv6 setups will use DHCPv6 on the WAN with prefix delegation enabled, and then toggle on "Track Interface" on the internal interfaces and select the WAN interface as the one to track with a configured /64 subnet identifier.
-
I think he was referring to DHCPv6 on the LAN, as he mentions Android devices. I don´t recall DHCPv6 being enabled by default, though there are some things it can be used for that SLAAC & RDNSS don´t provide. It isn't always used to provide a device address.
-
@JKnott said in Why does pfsense run dhcpv6 and slaac by default?:
I think he was referring to DHCPv6 on the LAN, as he mentions Android devices.
Yeah, you are probably correct. I read the original post too quickly and jumped to the wrong explanation.
-
Yah. I am talking about on the LAN side. I was trying to figure out why my devices had so many IPv6 addresses and discovered this. Once I turned it off then they had 1 less.
It didn’t really hurt anything, just seeing if I’m missing something or maybe it was overlooked in development.
-
With IPv6, devices can have multiple addresses. With SLAAC, you get up to 8 global addresses. One is consistent and the others are temporary privacy addresses, with a new one every day, up to 7. You also have a link local address and if you have ULA too, you will have up to 8 of them too. Then you can have more than 1 router, each providing more SLAAC addresses, etc..
-
Most people want the management capabilities of DHCPv6 on their LAN (e.g. static leases, seeing lease reports from hosts, that sort of stuff) but not all clients support DHCPv6 (e.g. Android's stupid decision to not implement a DHCPv6 client).
If it ran with only SLAAC enabled, people would complain they had no visibility for clients other than the NDP table.
So it runs with both by default and lets the user decide if they want to change it from there.
Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
Ok, that makes sense.
Thanks for the clarification @jimp
-
@jimp said in Why does pfsense run dhcpv6 and slaac by default?:
Most people want the management capabilities of DHCPv6 on their LAN (e.g. static leases,
With SLAAC, you get 1 consistent address, which you configure DNS for and up to 7 privacy addresses. No need for a static lease.
PfSense running on Qotom mini PC
i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
UniFi AC-Lite access pointI haven't lost my mind. It's around here...somewhere...
-
@JKnott said in Why does pfsense run dhcpv6 and slaac by default?:
@jimp said in Why does pfsense run dhcpv6 and slaac by default?:
Most people want the management capabilities of DHCPv6 on their LAN (e.g. static leases,
With SLAAC, you get 1 consistent address, which you configure DNS for and up to 7 privacy addresses. No need for a static lease.
Maybe so, but the problem is the firewall / router / DHCP server have zero knowledge of which addresses have been allocated/self-assigned and so on, clients would have to also self-register in DNS which they may not support. Even if the SLAAC address doesn't change, but that isn't necessarily the primary intent behind making it static in DHCP.
To get the address into DNS manually someone would have to check the address on the client, communicate that to whoever controls DNS, and then hope it doesn't change at a later time.
All of that is pretty well automatic with DHCPv6, with the benefit of being able to see the current allocated leases from the firewall.
-
@JKnott said in Why does pfsense run dhcpv6 and slaac by default?:
With SLAAC, you get 1 consistent address, which you configure DNS for and up to 7 privacy addresses. No need for a static lease.
That's not always true. If the prefix delegation changes, that "consistent" address also changes because the privacy algorithm that calculates the host part of the address is calculated from the /64 network part of the address. EUI-64 doesn't have this issue because the host part is always static, but very few devices still implement EUI-64 as it's technically been replaced by RFC4941.
Since most non-business ISP give out dynamic prefix that changes with every reconnect you'll get a different SLAAC address as well, which makes it all useless. With DHCPv6 you can assign a static host that registers in DNS and automatically updates even if your prefix changes.
-
-
@JKnott said in Why does pfsense run dhcpv6 and slaac by default?:
If the prefix changes, it will also change for DHCP. Also, what's the scope of the DNS? Global or local? If the DNS is local only, then you can use ULA to provided permanent addresses for devices on the LAN.
In DHCP you can set static assignments for host part only in the form of ::xx:xx:xx:xx and it will automatically update no matter the prefix given, and will automatically update DNS records as well. In SLAAC with RFC4941 a change in the prefix part will also trigger a change in the host portion of the address.
As for ULA, if you have a dual-stack option with both IPv4 and ULA IPv6 with both addresses registered in DNS, most devices will always prefer IPv4 over ULA IPv6 so there's literally no point in ever using ULA IPv6, especially if you have GUA IPv6 already setup. If your DNS record for the host contains IPv4 and GUA IPv6 it will use IPv6.
-
In my experience, IPv6 is preferred.
-
@JKnott said in Why does pfsense run dhcpv6 and slaac by default?:
In my experience, IPv6 is preferred.
RFC6724 mandates that IPv4 is preferred over ULA IPv6 but IPv6 GUA is preferred over IPv4. You can obviously manually bypass this by breaking RFC in Linux systems but can't be done for other embedded systems.
IETF is currently working on a draft to revert this behaviour and make IPv6 ULA preferred over IPv4 but it's not yet implemented. Until this is a thing and until all devices are updated or replaced to follow this updated draft, for now IPv4 has higher priority over IPv6 ULA.
Excerpt from relevant draft:
The current default policy table in RFC 6724 leads to preference for IPv6 GUAs over IPv4 globals, which is widely considered to be preferential behavior to support greater use of IPv6 in dual-stack environments, and to allow sites to phase out IPv4 as its use becomes ever lower.
However, the default policy table also puts IPv6 ULAs below all IPv4 addresses, including [RFC1918] addresses. For many site operators this behavior will be counter-intuitive, and may create difficulties with respect to planning, operational, and security implications for environments where ULA addressing is used in certain IPv4/IPv6 dual-stack network scenarios. The expected prioritization of IPv6 traffic over IPv4 by default, as happens with IPv6 GUA addressing, will not happen for ULAs. -
@IonutIT said in Why does pfsense run dhcpv6 and slaac by default?:
RFC6724 mandates that IPv4 is preferred over ULA IPv6 but IPv6 GUA is preferred over IPv4. You can obviously manually bypass this by breaking RFC in Linux systems but can't be done for other embedded systems.
I guess my computer hasn't read that RFC. Neither have I for that matter.
host firewall
firewall.jknott.net has address 172.16.0.1
firewall.jknott.net has IPv6 address fd48:1a37:2160:0:4262:31ff:fe12:b66cping firewall
PING firewall(firewall.jknott.net (fd48:1a37:2160:0:4262:31ff:fe12:b66c)) 56 data bytes
64 bytes from firewall.jknott.net (fd48:1a37:2160:0:4262:31ff:fe12:b66c): icmp_seq=1 ttl=64 time=0.313 ms
64 bytes from firewall.jknott.net (fd48:1a37:2160:0:4262:31ff:fe12:b66c): icmp_seq=2 ttl=64 time=0.162 ms
64 bytes from firewall.jknott.net (fd48:1a37:2160:0:4262:31ff:fe12:b66c): icmp_seq=3 ttl=64 time=0.136 ms
64 bytes from firewall.jknott.net (fd48:1a37:2160:0:4262:31ff:fe12:b66c): icmp_seq=4 ttl=64 time=0.120 ms
