Hello World,
like other people we had the problem that existing DHCPv6 servers do not
evaluate the MAC address of clients, following RFC 3315. The IPv4
clients already are managed via their MAC addresses so we wanted to use
these identifiers for IPv6 too for our dualstack network.
At the end we had to write our own DHCPv6 server dhcpy6d which I want to
present here to a larger audience. It runs on Linux, tested on Debian
and CentOS. It gets the client MAC addresses from neighbor cache by
calling "ip -6 neigh" and caches them itself, allowing to access the
already working MAC-based IPv4 infrastructure. This obviously only works
on the local subnet but might be worked around with several servers
being connected via database storage of clients and leases.
Features are:
- identifies clients by MAC address, DUID or hostname
- generates addresses randomly, by MAC address, by range or by given ID
- filters clients by MAC, DUID or hostname
- assignes more than one address per client
- allows to organize clients in different classes
- stores leases in MySQL or SQLite database
- client information can be retrieved from database or textfile
- dynamically updates DNS (Bind)
We run it with ~500 clients without problems. I am interested if it
would run in larger environments too. If not, how to make it running.
Bugs and ideas how to improve it are welcome too.
Packages are not yet available but the Python code should run as is.
cool. this is the fifth version of a DHCP server modified to work
with IPv4 and IPv6 in accord with the DHCP specs.
a feature request... some sites run IVI, and so the have a MAC and
and v6 address and need to be dynamically assigned a v4 address. My crude
attempt uses the last 48bits of the v6 address asa proxy MAC. It works
ok in my small network. It might be useful in larger nets that run IVI
or carrier-grade NAT ...
- identifies clients by MAC address, DUID or hostname
Excellent, identification by MAC address was often requested. Thanks
for this software.
like other people we had the problem that existing DHCPv6 servers do
not evaluate the MAC address of clients, following RFC 3315.
I'm not convinced that it is RFC's fault. The only thing I find in RFC
3315 is (section 9) "DHCP servers use DUIDs to identify clients for
the selection of configuration parameters and in the association of
IAs with clients." I read it as "a compliant DHCPv6 server MUST
recognize DUID and identify clients this way" which does not logically
imply that it cannot identify clients by other means as well.
If you're on local subnet, why not pull the MAC address out of the
received packet?
The used SocketServer module of Python has no support for raw sockets,
as far as I see. Let me know if there is a way to get the MAC in a
cleaner way.
Further, what happens to this when IPv4 goes away?
Will that day ever come? I think until this day a lot of RFCs will
be written. This server here just allows to make transistion easier.
And, it also allows the use of DUIDs, so it might work in an IPv6-only
world.
Shouldn't that do the trick? I don't know if Python can do that or not, but if it can't, that's pretty weak.
As far as I was able to find out this only gives back the local MAC
address which is of no use here.
To be independent of external call I at least for Linux managed to
access neighbor cache via netlink socket as the "ip" command itself
does. Thus no external call is necessary anymore.
I think until this day a lot of RFCs will