DHCPv6: Dibbler - a portable DHCPv6

News

2015-08-09: Dibbler 1.0.1 has been released. It contains a number of bug fixes that were already released in the 1.0.1 Release Candidate 1 and several new fixes. One of them may have security implications, so upgrade is strongly encouraged.

2014-07-13: The second Release Candidate for Dibbler 1.0.0 has been released. Due to other obligations, 1.0.0RC1 was available for a very long time and I never had a chance to release 1.0.0 final. In the mean time, quite a few of fixes and small features were added (Changelog mentions 35 items, but I'm sure some of them were not listed). So formally this is a second RC, but it contains unexpectedly large changes for an RC. Keep that in mind. This time I expect the delay between RC and final to be much shorter (couple weeks). Couple changes worth mentioning:

• dibbler client now configures received prefix with /128, not /64. This will likely raise some eyebrows, but that how DHCPv6 is supposed to work. Please see bug #222 for extra details.
• There are reports that Reconfigure messages are sent to the wrong address if the client connected via relays. See bug #303.
• There are reports that Dibbler has problems on Ubuntu 14.04. That was traced to a Linux kernel issue and is fixed in 3.15.2. See bug #302.
• Windows port improved, now using Visual Studio 2013 Express.
• Issue tracker on github has been disabled. It was awkward to use both bugzilla and github.

See CHANGELOG for a complete list of changes. If you find bugs, please report them on Dibbler bugzilla. If you need help or want to share your thoughts, take a look at one of two mailing lists: dibbler or dibbler-devel. Please do not contact author directly, unless you want to report security issues or discuss confidential matters.

2013-07-30: Dibbler 1.0.0 Release Candidate 1 has been released! This version is being released today to celebrate 10th anniversary of the DHCPv6 protocol. The RFC3315 that defines it was published exactly 10 years ago - on 30th July of 2003. According to the author's knowledge, Dibbler is currently the only implementation that implements every feature mentioned in the RFC3315. Please note that feature complete does not mean bug free ;-) This release brings in all outstanding RFC3315 features that used to be missing in previous releases. In particular:

• Reconfigure support. Server is now able to load database, check it against existing configuration and send reconfigure to clients that have configuration out of date. Clients are able to accept incoming reconfigure messages and initiate reconfiguration.
• Reconfigure-key authentication. Server is now able to generate reconfigure-key when responding to clients and later use that key to sign reconfigure messages. Clients are able to store received key and later confirm that incoming reconfigure message is properly signed.
• Delayed authentication - clients and server are able to leverage pre-configured keys to sign later parts of the messages exchange.
• Dibbler authentication - it is a rewritten mechanism used in earlier versions. It has number of advantages compared to delayed authentication, but has a number of advantages over it. First, it secures the whole transmission, including initial SOLICIT message. Second, it offers much stronger digests: HMAC-MD5, HMAC-SHA1, HMAC-SHA224, HMAC-SHA256, HMAC-SHA384 and HMAC-SHA512. As this is Dibbler specific extension, it is not expected to inter-operate with any other implementations. Third, it does not require to maintain strict client DUID-key-id bindings on the server side, as clients send ID of the key they used to protect their transmissions.
• Replay detection - both client and server can now detect whether receiving message is a new one or it is replayed by attacker.
• Client is now able to act according to received M(managed) and O(Other configuration options) in Router Advertisements, if configured to do so.
• Server and client now checks database against changes in the network interfaces and tries to update it if possible. That should be helpful if you happen to lost and recreated an interface (e.g. broken ppp connection).

Enjoy!

2013-06-27: Dibbler 0.8.4 has been released. There is no single major new feature, just a lot of bug fixes: 34 bug fixes, tweaks and small improvements since 0.8.3. Vendor class and User class methods are now implemented. Relay support has been rewritten. It is now possible to select subnet based on interface-id or value of linkaddr field set by the relay. Client classification has been improved and now can be used to differentiate between 2 or more classes, e.g. docsis3.0 and eRouter in cable networks. Confirm support has been cleaned. Daemon mode no longer has issues when reading from socket descriptor 0. The database format has changed a bit. It now stores interface names, not just interface indexes. That is helpful in cases your interfaces has changed, e.g. when your ppp0 interface went down and was recreated with different ifindex. Opening up old database should be seamless, but make sure you make a backup before migrating to 0.8.4. Dibbler server no longer does by default destination address filtering against the addresses sockets are bound to. If that bothers you, because on your OS you see the same incoming packet being received over two sockets, please use --enable-dst-addr-check in configure phase.

2013-04-27: Dibbler 0.8.4 Release Candidate 1 has been released. There is no single major new feature, just a lot of bug fixes. In particular, relay support has been rewritten. It is now possible to select subnet based on interface-id or value of linkaddr field set by the relay. Client classification has been improved and now can be used to differentiate between 2 or more classes, e.g. docsis3.0 and eRouter in cable networks. Confirm support has been cleaned. Daemon mode no longer has issues when reading from socket descriptor 0. See CHANGELOG for a complete list of changes.

2013-01-20: Dibbler 0.8.3 has been released. The biggest feature is a rewritten address and prefix allocation engine. Both follow the same algorithm now. It is possible to reserve specific address and/or prefix for a given host. The host can be referenced by DUID, remote-id or link-local address. Both in-pool and out-of-pool reservations are now supported. Support for DDNS is now significantly improved. Secure DNS Updates using TSIG are now supported. Many, many bugs were fixed and the FQDN handling code is now much more robust. The code now compiles on Solaris 11. It is not yet fully usable, and there are outstanding problems with link-layer address detection, but it is better than nothing. Script execution is now improved as well. It is called when receiving stateless configuration (after receiving reply to INF-REQUEST) and extra options (like FQDN and vendor-specific info) are now properly passed. See CHANGELOG for a complete list of changes.

2011-11-13: Dibbler 0.8.1 Release Candidate 1 is released. This release introduces number of useful additions, new features and the usual bug fixes. In particular, the highlights of this release are:

• Support for routing configuration was added. Yes, you read that correctly. Recent draft draft-ietf-mif-dhcpv6-route-option defines provisioning mechanism that delivers routing information over DHCPv6. Although this implementation is not entirely complete (there are certain limitations, see User's Guide), it is very usable. This feature was tested with excellent ISC DHCP implementation and is interoperable. You may want to read Routing configuration over DHCPv6 for additional information.
• Script support is rewritten. Client can call a script every time it receives a message and pass all received options as environment variables. That is very convenient way to extend client with custom actions. This feature is going to be further expanded in upcoming releases.
• Server is now able to run scripts, too. That is convenient if you need your server to execute custom actions. One notable example is a routing reconfiguration after prefix was delegated to a client.
• Added support for FreeBSD, NetBSD and OpenBSD. Mac OS X support is now also significantly improved. To achieve this level of portability, build system was completely rewritten and is now using automake and autoconf tools. You can now use ./configure script to enable or disable various parameters. Makefile modification is no longer necessary.
• DNS Update can now be performed over UDP, TCP or both (try over UDP and if it fails, try TCP). Configurable timeout for DNS Updates added.
• Significant update in prefix delegation support. Server will now remember previously assigned prefixes and will try to assign the same prefix to returning client.
• Support for DS-Lite tunnels configuration added (RFC6334)
• Rather large User's Guide documentation update
• Fixed mis-aligned memory reads on ARMv5 architecture
• Added support for unittests using googletests. Number of tests is small now, but is expected to grow.

2011-09-05: Dibbler source has been moved to GIT repository at github.

2011-05-11:Dibbler 0.8.0 has been released. That is a new release after long time. Dibbler development just resumed.

2011-03-14: I got my first mac! Yay! After figuring out how to do anything useful without insert, delete, pgup and pgdown, I think I was able to fix many problem with Mac OS port. I'm able to run both client and server on my mac. If you have Mac hardware available, please Get the latest code from SVN and give it a try.

2011-02-11: I'm happy to announce that my 7 year struggle to complete my Ph.D. is finally over. It appears that I will finally have some time to reinvigorate Dibbler. There are many things happening lately in DHCP world, so it seems I'll be busy in the near future. In the mean time, Dibbler became quite outdated. Please send a note to the mailing list regarding missing features that you find the most urgent to develop.Cheers, Tomasz Mrugalski, Ph.D.

2010-09-17: Good news, everyone! After a year and a half, I finally found some time to wrap everything that was slowly going around, packed and released 0.8.0 Release Candidate 1. The major changes include support for Windows 7 and Mac OS (both experimental), support for CONFIRM, client and server will reload their databases during boot, Linux console now can be colorful, support for bunch of experimental stuff added. Finally, there's large code refactoring taking place, so let's hope that everything is working... Enjoy

Old news: [2009-2007] [2006 and older]

Feature List

• Server discovery and address assignment (SOLICIT, ADVERTISE, REQUEST and REPLY messages) - This is a most common case: client discovers servers available in the local network, then asks for an address (and possibly additional options like DNS configuration), which is granted by a server.
• Best server selection - when client detects more than one server available (by receiving more than one ADVERTISE message), it chooses the best one and remembers remaining ones as a backup.
• Relay support - In a larger network, which contains several Ethernet segments and/or wireless areas, sometimes centrally located DHCPv6 server might not be directly reachable. In such cace, additional proxies, so called relays, might be deployed to relay communication between clients and a remote server. Dibbler server supports indirect communication with clients via relays. Standalone, lightweight relay implementation is also available. Clients are capable of talking to the server directly or via relays.
• Leasequery - From the sysadmin's perspective, it is often beneficial to check which address has been assigned to a specific client or who got a specific address. To do so, it is possible to query server for such information. There is a special type of DHCPv6 entity called requestor that performs such queries and parses server's answers.
• Address renewal - After receiving address from a server, client might be instructed to renew its address at regular intervals. Client periodically sends RENEW messege to a server, which granted its address. In case of communication failure, client is also able to attempt emergency address renewal (i.e. it sends REBIND message to any server).
• Unicast communication - if specific conditions are met, client could send messages directly to a server's unicast address, so additional servers does not need to process those messages. It also improves effciency, as all nodes present in LAN segment receive multicast packets.
• Duplicate address detection - Client is able to detect and properly handle faulty situation, when server grants an address which is illegaly used by some other host. It will inform server of such circumstances (using DECLINE message), and request another address. Server will mark this address as used by unknown host, and will assign another address to a client.
• Power failure/crash support - After client recovers from a crash or a power failure, it still can have valid addresses assigned. In such circumstances, client uses CONFIRM message, to config if those addresses are still valid.
• Normal and temporary addresses - Depending on its purpose, client can be configured to ask for normal (IA NA option) or temporary (IA TA option). Although use of temporary addresses is rather uncommon, both dibbler server and client support it.
• Hint system - Client can be configured to send various parameters and addresses in the REQUEST message. It will be treated as a hint by the server. If such hint is valid, it will be granted for this client.
• Server caching - Server can cache granted addresses, so the same client will receive the same address each time it asks. Size of this cache can be configured.
• Stateless mode - Client can be configured to not ask for any addresses, but the configuration options only. In such case, when no addresses are granted, such configuration is called stateless (INFORMATION-REQUEST message is used instead of normal REQUEST).
• Rapid Commit - Sometimes it is desirable to quicken configuration process. If both client and server are configured to use rapid commit, address assignment procedure can be shortened to 2 messages, instead of usual 4. Major advantage is lesser network usage and quicker client startup time.

Also following extensions are supported:

• DNS Servers - During normal operation, almost all hosts require constant use of the DNS servers. It is necessary for event basic operations, like web surfing. DHCPv6 client can ask for information about DNS servers and DHCPv6 server will provide necessary information.
• Domain Name - Client might be interested in obtaining information about its domain. Properly configured domain allow reference to a different hosts in the same domain using hostname only, not the full domain name, e.g. alice.example.com with properly configured domain can refer to another host in the same domain by using 'bob' only, instead of full name bob.example.com.
• NTP Servers - To prevent clock misconfiguration and drift, NTP protocol can be used to synchronize clocks. However, to successful use it, location of near NTP servers must be known. Dibbler is able to configure this information.
• Time Zone - To avoid time-related ambiguation, each host should have timezone set properly. Dibbler is able to pass this parameter to all clients, who request it.
• SIP Servers - Session Initiation Protocol (SIP) is commonly used in VoIP solutions. One of the necessary information is SIP server addresses. This information can be passed to the clients.
• SIP Domain Name - SIP domain name is another important parameter of the VoIP capable nodes. This parameter can be passed to all clients, who ask for it.
• NIS, NIS+ Server - Network Information Service is a protocol for sharing authentication parameters between multiple Unix or Linux nodes. Both NIS and NIS+ server adresses can be passed to the clients.
• NIS, NIS+ Domain Name - NIS or NIS+ domain name is another necessary parameter for NIS or NIS+. It can be obtained from the DHCPv6 server to all clients, who require it.
• Option Renewal Mechanism (Lifetime option) - All of the options mentioned on this list can be refreshed periodically. This might be handy if one of those parameters change.
• Dynamic DNS Updates - Server can assign a fully qualified domain name for a client. To make such name useful, DNS servers must be informed that such name is bound to a specific IPv6 address. This procedure is called DNS Update. There are two kinds of the DNS Updates: forward and reverse. First is used to translate domain name to an address. The second one is used to obtain full domain name of a known address.
• Prefix Delegation - Server can delegate a prefix to a client. That feature is intended to be used mainly by routers, which obtain prefixes from an upper level router. Client after receiving prefix, will generate smaller prefixes for each available interface.

Download: stable

Here's newest stable version. If you need, for some reason, older releases, you can find them in the dibbler directory.