dhcpy6d - a MAC address aware DHCPv6 server
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. See further details at http://dhcpy6d.ifw-dresden.de Best regards Henri Wahl -- Henri Wahl IT Department Leibniz-Institut für Festkörper- u. Werkstoffforschung Dresden tel. (03 51) 46 59 - 797 email: h.wahl@ifw-dresden.de http://www.ifw-dresden.de Nagios status monitor for your desktop: http://nagstamon.ifw-dresden.de IFW Dresden e.V., Helmholtzstraße 20, D-01069 Dresden VR Dresden Nr. 1369 Vorstand: Prof. Dr. Ludwig Schultz, Dr. h.c. Dipl.-Finw. Rolf Pfrengle
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 ... /bill On Mon, Nov 05, 2012 at 09:14:54AM +0100, Henri Wahl wrote:
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.
See further details at http://dhcpy6d.ifw-dresden.de
Best regards Henri Wahl
-- Henri Wahl
IT Department Leibniz-Institut f|r Festkvrper- u. Werkstoffforschung Dresden
tel. (03 51) 46 59 - 797 email: h.wahl@ifw-dresden.de http://www.ifw-dresden.de
Nagios status monitor for your desktop: http://nagstamon.ifw-dresden.de
IFW Dresden e.V., Helmholtzstra_e 20, D-01069 Dresden VR Dresden Nr. 1369 Vorstand: Prof. Dr. Ludwig Schultz, Dr. h.c. Dipl.-Finw. Rolf Pfrengle
On Mon, Nov 05, 2012 at 09:14:54AM +0100, Henri Wahl <h.wahl@ifw-dresden.de> wrote a message of 155 lines which said:
- 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? Further, what happens to this when IPv4 goes away? Owen On Nov 5, 2012, at 12:14 AM, Henri Wahl <h.wahl@ifw-dresden.de> wrote:
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.
See further details at http://dhcpy6d.ifw-dresden.de
Best regards Henri Wahl
-- Henri Wahl
IT Department Leibniz-Institut für Festkörper- u. Werkstoffforschung Dresden
tel. (03 51) 46 59 - 797 email: h.wahl@ifw-dresden.de http://www.ifw-dresden.de
Nagios status monitor for your desktop: http://nagstamon.ifw-dresden.de
IFW Dresden e.V., Helmholtzstraße 20, D-01069 Dresden VR Dresden Nr. 1369 Vorstand: Prof. Dr. Ludwig Schultz, Dr. h.c. Dipl.-Finw. Rolf Pfrengle
Oh, horrors, part of my infrastructure needs raw socket data? We should ban that, for security. Who needs those pesky switches anyways? George William Herbert Sent from my iPhone On Nov 6, 2012, at 5:49 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Tue, Nov 06, 2012 at 05:38:32AM -0800, Owen DeLong <owen@delong.com> wrote a message of 68 lines which said:
If you're on local subnet, why not pull the MAC address out of the received packet?
Because it requires access to raw sockets, which should not be necessary for DHCP?
FWIW ISC DHCPd listens on raw sockets. On Tue, Nov 6, 2012 at 11:12 AM, George Herbert <george.herbert@gmail.com> wrote:
Oh, horrors, part of my infrastructure needs raw socket data?
We should ban that, for security. Who needs those pesky switches anyways?
George William Herbert Sent from my iPhone
On Nov 6, 2012, at 5:49 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Tue, Nov 06, 2012 at 05:38:32AM -0800, Owen DeLong <owen@delong.com> wrote a message of 68 lines which said:
If you're on local subnet, why not pull the MAC address out of the received packet?
Because it requires access to raw sockets, which should not be necessary for DHCP?
-- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
Hi,
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. Regards Henri -- Henri Wahl IT Department Leibniz-Institut für Festkörper- u. Werkstoffforschung Dresden tel. (03 51) 46 59 - 797 email: h.wahl@ifw-dresden.de http://www.ifw-dresden.de http://nagstamon.ifw-dresden.de http://dhcpy6d.ifw-dresden.de IFW Dresden e.V., Helmholtzstraße 20, D-01069 Dresden VR Dresden Nr. 1369 Vorstand: Prof. Dr. Ludwig Schultz, Dr. h.c. Dipl.-Finw. Rolf Pfrengle
On Tue, Nov 06, 2012 at 05:38:32AM -0800, Owen DeLong wrote:
If you're on local subnet, why not pull the MAC address out of the received packet?
Further, what happens to this when IPv4 goes away?
Owen
"the cat came back" ... IPv4 is going away like RIP is a dead routing protocol. give it another 20 years. /bill
participants (6)
-
bmanning＠vacation.karoshi.com -
George Herbert -
Henri Wahl -
Owen DeLong -
Ray Soucy -
Stephane Bortzmeyer