Deny unknown clients for DHCPv6 server
Is it possible to configure the DHCPv6 server to ignore unknown clients, similar to the DHCPv4 server option?
There are some subnets where I use static DHCP assignments for hosts that I expect to see, and do not want to provide IP addresses to any others.
Unfortunately, on the IPv6 side it appears that the only options are to provide at least a small range of non-static addresses that the DHCPv6 server will hand out to any unknown client, or disable DHCPv6 altogether.
Gertjan last edited by
DHCPv6 server to ignore unknown clients
Your question is old ^^
Read for example https://lists.isc.org/pipermail/dhcp-users/2012-July/015708.html ( started here https://lists.isc.org/pipermail/dhcp-users/2013-April/016687.html ).
Remember isc.org is the creator of dhcpdv6.
It's all about the DUID which can't treated as the MAC. The DUID of a device can change (even a MAC can change over time, the user can change it).
What's left to do ?
Make a small IPv6 DHCPv6 pool, and allow with firewall rules these IPv6.
Devices on the LAN can still auto assign a fe80.... local link IPv6 so they can communicate with other LN based devices You can't stop that from happening, if these device have access to your LAN.
@gertjan Thanks for the clarifications. I hadn't thought to look upstream, as I had assumed the functionality was there but not being presented in the UI.
In this case, these are hosts (VMs, actually) that I admin, so I don't expect the MAC to change once brought online, but I have run into the DUID changing in the past due to changes to the DHCPv6 client. I run radvd in managed mode, so clients are not instructed to try to get SLAAC addresses.
The purpose of this is more so to use it as a guardrail in case a host gets brought up on the subnet by mistake or without being "pre-provisioned" where someone makes an explicit effort to document the new host and assign it an address. In other words, if it comes up and has connectivity, I don't want someone, including myself, to mistaken think they did everything they needed to and have some rogue host sitting out there unaccounted for.
Based on what you're suggesting, it sounds like I can create an alias with LL addresses that should be allowed to multicast for DHCPv6 on that subnet, then put in a rule to allow those to pass through to the firewall interface, and drop solicits from all other hosts.