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.

Download: development version

Sources can also be downloaded from GIT repository:

git clone git://github.com/tomaszmrugalski/dibbler.git

You can also browse source directly with your web browser: Dibbler sources at github.

Old sources can also be downloaded from SVN. These sources are outdated and keep around only for several students that are doing their master theses. They can compare changes here. Everyone should migrate to GIT. If you really have a reason to use this old version, please use following command to download SVN sources:

svn checkout https://anonymous@klub.com.pl/var/svn/dibbler/trunk

Short-term goals (aka TODO)

Bugzilla is a bug tracking system. It allows to report, assign and deal with bugs in a convinient manner. It can also be used to request new features. It is called enhancement. Take a look at bugs with severity ("Sev" column) set to "enh". You can define what are you looking for by hand, or use one of the links on the side panel.

Long-term goals (aka Roadmap)

There's list of features, which I would like to include someday. In some far, distant, not so sure future. I'm really busy person, sorry. In parenthesis there are estimated versions, where this feature will be implemented.

• (0.4.0) RELAY AGENT support [done]
• (0.5.0-RC1) temporary addresses support (IA_TA option) [done]
• (0.5.0-RC1) DNS updates (FQDN option) [done]
• (0.6.0-RC1) Prefix Delegation [done]
• (0.7.0) Leasequery (RFC5007)
• (0.7.0) Authentication [done]
• (0.7.1-CVS)crash/power outage recovery (CONFIRM message)[done]
• (0.8.0) Mac OS X port
• (0.8.1RC1) DNS Updates over UDP
• (0.8.1RC1) FreeBSD/NetBSD/OpenBSD port
• (0.8.1RC1) Routing configuration (draft-mif-dhcpv6-route-option)
• (0.8.3RC1) Proper lease expiration support (with external script support)
• (0.8.3RC1) DNS Update security (TSIG)
• (0.9.0) Better client reservation (subscriber-id, relay-id link address)
• (0.9.0) Better client classification support (DUID, link address, relay-id etc.)
• (0.9.0) RECONFIGURE support
• (0.9.0) Universal new option definition (with external script support)
• (1.0.0) Remaining RFC3315 features
• Bulk leasequery
• DOCSIS 3.0 options
• (under consideration) Minimal client for embedded devices
• (under consideration) allow DB storage in a real database (PostgreSQL probably)
• DHCPv6 Failover (once the draft becomes solid enough)

If you are thinking about joining or contributing to the dibbler project, you may want to see this Developer's TODO list.

Looking for sponsor

During Dibbler development, I have encountered several problems with equipment availability. This project has no budget and I develop everything in my home. I have several computers, so I can build basic configuration. However, I don't have any fancy hardware, so I can't verify any of the more advanced setups.

Another issue that I have encountered is a lack of access to non-x86 architectures. I would like to develop Dibbler versions for other architectures, eg. 64-bit or Mac. So, if you are a well prospering company and you find Dibbler useful, consider supporting open source development and donating some of your equipment.

In further Dibbler development, access to the following equipment would be useful:

• An Intel 64-bit box
• AMD64 box
• A MAC capable of running Mac OS X
• Sun Sparc with Sun OS supporting IPv6
• A Cisco router capable of running DHCPv6 relay
• a LinkSys Wireless router WRT54G (which already supports Dibbler)
• A PDA with a network interface
• Any other uncommon hardware which would be able to run Dibbler

Mailing lists

USERS: Mailing list was created to support Dibbler users. Feel free to discuss any topic related to Dibbler or DHCPv6 in general. You can also ask for help here. If you want to subscribe, please send mail with subject "subscribe" to dibbler-request(at)klub.com.pl. You will receive confirmation request shortly. You can also subscribe to mailing list using www browser. There are list archives available.

DEVELOPERS: Second list is dedicated to free exchange of thoughts between people engaged in the Dibbler development. Sadly, this list will be even more desolated then the previous one. If you want to subscribe, please send mail with subject "subscribe" to dibbler-devel-request(at)klub.com.pl. You will receive confirmation request shortly. You can also subscribe to mailing list using www browser. There are list archives .

Requirements

This implementation is developed using tools listed below. It may, of course, work with newer/older versions. Even with other compilers. Marek Senderski developed WinXP version using microsoft Visual C++ 2003, 2005 and 2008 editions. Bison++ has been merged into CVS, so there should be no more problems with obtaining bison++. Note that bison++ is available in Debian GNU/Linux distribution. In parenthesis is version which has been used to develop Dibbler. It will work for sure, but there's pretty good chance that other versions will work, too. Here's the list:

• gcc (2.95 to 4.7.2)
• g++ (2.95 to 4.7.2)
• flex (2.5.35 or later)
• bison++ (1.21.9, sources included in git)
• libxml2 (with pkg-config in Linux)

To generate Windows installer, a cool Inno Setup tool was used. Dibbler User's Guide was written in LaTeX, Dibbler Developer's Guide was generated using Doxygen.

Older versions

All versions are stored in the /dhcpv6/dibbler/ directory. Take note that they are kept for archeological/sentimental purposes only. Please use latest version only.