(Perhaps some phrases to Router Advertisements should be changed to the more generalized term of Router Discovery Messages.) [#dhcpv6sv]:
DHCPv6 Servers: Servers for DHCP for IPv6 (DHCPv6, a.k.a. DHCP6)
(This section is part of the section about servers. It may be focused mostly on servers. See also the section on DHCPv6 clients.)
This protocol is documented by RFC 3315 (DHCPv6)
DHCPv6 is not necessarily expected to replace router advertisements. For instance, OpenBSD CVSWeb patch file for dhcp6s.conf.sample (version 18.104.22.168). notes, “Note. You have to send an RA to ” to the NIC. “otherwise a client cannot be sure about the prefix-length and the default router. If you want to prevent stateless address configuration via RA,” causing the routing advertisement software to set a relevant configuration bit can accomplish this. (Note: That is some old information, which may or may not still be valid.)
- Interaction with NDP router advertisemenets
NDP and SLAAC may specify to use DHCPv6 for choosing addresses, as determined by the Managed bit. For more information on setting that bit, see details about setting up the NDP/SLAAC “servers” (in the specifications these servers are often called ”routers”). However, as some hints how to do so: OpenBSD Manual Page for the rtadvd.conf file: “Capabilities” section refers to raflags: Using 0x40 sets other.
- Overview: Information that gets provided by DHCPv6
DHCPv6 may provide multiple pieces of information, including IPv6 addresses that an IPv6 client may use and other information such as DNS servers. When DHCPv6 is used simply to provide information which is common to multiple machines, the phrase “stateless mode” may be used. This is in contrast to a mode which is not stateless, where DHCPv6 keeps track of any address it assigns to a client (so that the server does not assign the same address to another machine before the lease is up).
- [#dhc6rsrv]: Necessity of a “DHCPv6 Unique Identifier” (e.g. used for DHCPv6 reservations)
Handling DHCPv6 reservations typically/always involves using a “DHCPv6 UID” (a.k.a. “DUID”). (This abbreviation DUID is quite unrelated to the “disklabel UID” used with BSDLabels. As the term is based on the abbreviation “UID”, it seems sensible that, at least eventually over time, the abbreviation “DUID” may have additional common meanings.)
RFC 3315 (DHCPv6): Section 9 (DHCPv6 UID) states, “Clients and servers MUST treat DUIDs as opaque values and MUST only compare DUIDs for equality. Clients and servers MUST NOT in any other way interpret DUIDs.” (This is funny: since DUIDs may be derived by link-local addresses, a client could extract a link-local address, but the RFC says it MUST NOT do this. Of course, with DUID-LLT, such a link-local address, if extracted (in violation of the specification), would just represent a link-local address from when the the DUID was created. Another example is that DUID-LLT may show an indication of when the DUID was created.) The RFC 3315 (DHCPv6): Section 9 (DHCPv6 UID) does state, “The DUID is carried in an option because it may be variable length and because it is not required in all DHCP messages.” However, the most common method for a DHCPv6 server to support reserving addresses is to use a DUID.
RFC 3315 (DHCPv6) Section 9 (“DHCP Unique Identifier (DUID)”) notes “Each DHCP client and server has a DUID.”
- Format of a DCHPv6 UID
The length of a DUID may vary.
RFC 3315 (DHCPv6) Section 9 (“DHCP Unique Identifier (DUID)”) states, “The DUID is designed to be unique across all DHCP clients and servers, and stable for any specific client or server - that is, the DUID used by a client or server SHOULD NOT change over time if at all possible; for example, a device's DUID should not change as a result of a change in the device's network hardware.” Some similar language in the same RFC notes, “the same DUID-LLT SHOULD be used in configuring all network interfaces connected to the device, regardless of which interface's link-layer address was used to generate the DUID-LLT.” (Note that the phrase “SHOULD” is being used, not the phrase “MUST”. People familiar with RFCs will understand that these capatalized terms are defined by an RFC, namely IETF BCP 14 (which has been RFC 2119 for at least (almost/nearly) a decade and a half). So, engineers makers MUST NOT assume that this behavior is always followed.)
A DUID may still be based on a MAC, similar to DHCP for IPv4's typical implementation of using a NIC's EUI-48/MAC address as an identifier. The fact that this is commonly done is shown by RFC 6355 mentioning DUID-LL. However, in case a NIC may be moved to another machine, it is better to use DUID-LLT which includes a timestamp as well. That way another machine doesn't end up using the same DUID. If the NIC does ever get replaced, the general expectation is that the machine continues to use the same previously-saved DUID, because DUIDs should not change.
A DUID needs to start with a two-byte type code, and then may be up to an additional 128 bytes (which would be commonly renderable as 256 hexadecimal digits) as described by RFC 3315: DHCPv6, section 9.1: DUID contents.) If the first two bytes are 0x0001 then the rest of the DUID is based on the format described by RFC 3315: DHCPv6, section 9.2: “DUID Based on Link-layer Address Plus Time [DUID-LLT]”. So, the whole address may be rather predictable, except for the timestamp piece. If the first two bytes are 0x0002, then the address is meant for use by an organization listed at IANA's Enterprise Numbers assignments, as mentioned by RFC 3315: DHCPv6, section 9.3: “DUID Assigned by Vendor Based on Enterprise Number [DUID-EN]” If the first two bytes of the address are 0x0003, then the address is meant to be created using the guidelines at RFC 3315: DHCPv6, section 9.4: “DUID Based on Link-layer Address [DUID-LL]”. This ends up being like DUID-LLT but lacks the bytes that contain a timestamp. RFC 3315 (DHCPv6): Section 9 (DHCPv6 UID) states, “Clients and servers MUST NOT restrict DUIDs to the types defined in this document, as additional DUID types may be defined in the future.” If the first two bytes of the address are 0x0004, then RFC 6355: “UUID-Based DHCPv6 Unique Identifier (DUID-UUID)” covers the format of the remaining bytes.
Of all those various formats, the most likely format of a DUID might be DUID-LLT. It specifies that the next two bytes are assigned by IANA, and related to RFC 826 which basically describes ARP. RFC 826 may not refer to IANA, but IANA page listing protocols does refer to IANA ARP Parameters as the “Hardware Types” document. This document identifies Ethernet as the hardware type of 01. So, the first four bytes of many DUIDs may be 0x00010001.
The next bits of a DUID-LLT consists of a timestamp representing a number of seconds since the beginning of the third millenium A.D. (The website at UnixTimeStamp.com will provide the current time as an appropriate number for the current time. The first trick to then perform is to subtract 39,836,476,416 decimal (0x946706400 hex) from what the website gives, since UnixTimeStamp.com uses the Unix time epoch of the first second of 1970 A.D., but DUID-LLT uses a time epoch of the third millenium A.D. The other trick, then, is making sure the results are coverted to hexadecimal.) An alternative which isn't quite as good to deploy would be to start the DUID with 00:03: and then skipping the timestamp bits, although this isn't as preferred, as another client using the same MAC address (e.g. if the NIC moved) could end up using the identical DUID. That's less of a concern for NICs embedded on a motherboard, as they are less likely to be getting moved to a new device.
Then, after the four byte timestamp, the remaining bits may commonly be (quite visibly) identical to the link layer (e.g. hardware/MAC/EUI-48) address.
A DUID that starts with something other than 00:01: or 00:03: may have very different patterns/specifications. So, for instance, they may not even be including a MAC address. The shortest format using a standard defined type may be a DUID-EN that starts with 00:02: and which consists of 1,536 bits (although the “variable length” might not have intended to mean zero bits, and the DUID is a DHCPv6 option so it should be a multiple of eight bits long, as noted by the couple of first sentences of RFC 3315: DHCPv6, page 17 (in section 6: Client/Server Message Formats).
(The following paragraph may be redundant with the above info...) RJ Systems: Linux System Administration: DHCPv6 stateful autoconfiguration: section 7 “Client DUID file replacement” notes, “For a DHCPv6 server to assign a static IPv6 address to a particular DHCPv6 client, it must identify that client by its DUID, almost the same as a DHCPv4 server can lease an address to a client after identifying it by its MAC address.”
To determine a valid DUID (of this type) for an installation of DHCPv6 client software, see the section about DHCPv6 clients. (Details might be specific to certain client software.)
If a reservation is going to be made, it may make sense to get the required information from the client before setting up the server. (This is similar to how it may make sense to gather a MAC address before setting up DHCP for IPv4. In both cases, if that information is not very conveniently obtainable then another sensible course of action may be to just ignore the reservation temporarily, and then set up the reservation after the server's basic operation has been set up.) For a DUID, getting this information may require running the client at least once (even if the server isn't yet operational).
Perhaps the server software/logs has some way to report the DUIDs of the clients that use that server? (If so, this would likely vary based on implementation.)
RJ Systems: Linux System Administration: DHCPv6 stateful autoconfiguration: section 7 “Client DUID file replacement” says, “the DUID is generated when the client is installed” and this DUID gets “saved as /var/lib/dhcpv6/dhcpv6c_duid.”
However, the WIDE DHCPv6 package for OpenBSD has its manual page state the DUID is stored in /var/db/dhcpv6c_duid so the precise location may vary even for the same software. Michigan Tech DHCPv6 example notes the file for Dibbler may be client-duid (for Microsoft Windows, this would be in the location where the software is installed to).
- [#dhcpv6rt]: Routing information in DHCPv6
- Standardization Status
At the time of this writing, supporting routing with DHCPv6 does not appear to be a widely accepted standard.
RFC 6104: Rogue IPv6 Router Advertisement Problem Statement: section 3.10: “Adding Default Gateway/Prefix Options to DHCPv6” discusses the concept of changing DHCPv6 not having that support.) It does make a reference to “[DHCPv6-DEFAULT-RTR]” which may be seen by viewing Tracker for Droms DHCPv6 Default Router and choosing to view the “html” format. An ISC blog entry about using routing with DHCPv6 refers to another proposal for this feature, which may be seen by Tracker for Internet Draft of DHCPv6 route option. That proposal has had at least a half-dozen drafts, and seems to actually be implemented (by ISC DHCP). However, at the time of this writing in September of 2013, both proposals appear to be stagnant and the drafts have entered the state of being “expired”.
- Observations from around 2011-2013
Dibbler's page notes, for Dibbler 0.8.1 Release Candidate 1 (Nov 13, 2011 A.D.), “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.” The referenced User's Guide is a PDF file at http://klub.com.pl/dhcpv6/doc/dibbler-user.pdf
- Observations from September 2013
For years, such routing information was not available using a standardized process, and the intent was for network administrators to rely on “router advertisements” for distributing the routing information.
Now, that may have finally started to change (and may have changed already by the time this has been read).
An ISC blog entry about using routing with DHCPv6 was written November 8, 2011, and stated, “Currently the DHCPv6 protocol does not allow the provisioning of any routing-related information to hosts. A new proposal is addressing this shortcoming.” ... “Router Advertisement (RA) messages” may be used... “Currently, that is the only reasonable way of provisioning routing information to hosts. The other alternatives are usually avoided.” ... A draft exists and was making the progress of going through the standardization process, “so it is expected to be approved and published soon.” ... “It also allows configuration of the default route and availability of local on-link route(s). In a sense, it makes DHCPv6 complete, as it no longer requires RAs to operate.”
It looks like ISC DHCP started to support this in a rather indirect fashion. Rather than just allowing a new option specific to a default gateway, the configuration file gained some support for having the structure of a new option. So, the first thing the configuration does is provide information about what the option looks like, and then the option is used to be able to provide information.
This approach seems to add flexibility to the software (to more easily support new options in the future), while adding more than absolutely minimal complexity to the structure of configuration files whenever a fairly standard desire (to share routing information) is used.
DHCPv6: Dibber - a portable DHCPv6 states, “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 ;-)” (Hyperlink added to quoted material.)
Dibbler might not be the most popular/wide-spread DHCPv6 server, but its home page is being quoted to point out that it has taken 10 years to support each DHCPv6 feature, and no other server had yet achieved that feat (as far as that author knew). Likely as the result of standards authors endorsing “router advertisements” and DHCPv6 being viewed as less necessary, DHCPv6 itself has just not become quite as thoroughly explored as the common features of DHCP/IPv4. With DHCPv6 itself being a technology that did not gain rapid deployment, certainly the less supported added option of supporting routing has received far less usage and testing.
The whole situation feels rather un-solidified (especially including the fact that the documentation being cited was referring to a “draft” standard). The documentation found on ISC's site, dated November 8 of 2011, makes it sound like standardization is an actively happening thing. Whether there is much activity or not, the fact is that the standardization process was still at work many months later (Draft 5 was published August 24, 2012). When checked in September of 2013, Draft 5 had expired February 25, 2013.
Keep in mind that even if the feature does work with some devices on a network, other devices may not support the feature. Even if the feature has become an official standard, or if the feature becomes an official standard as early/soon as tomorrow, there has been quite a bit of time where many IPv6-capable devices might not support this feature. (Even if all of the devices on a network do support the feature, at some point an additional device might be plugged into the network, and might not support the feature.)
The recommendation being made as of September 2013 is to re-visit this topic at a later time, and see whether the feature seems to have advanced to the point of receiving an official RFC.) In the meantime, people looking for more established technologies may want to really consider just using “router advertisements”, as that will probably be the more compatable solution that will work with more IPv6 implementations. Those who are more adventurous may want to check for some newer documentation that may be updated. (In other words, use search engines to see if some interesting and newer text identifies any recent activity towards a standard that may receive more wide-spread support.) The really adventurous may want to check out some of the pre-existing documentation about implementations created so far, such as ISC DHCP's support, see: An ISC blog entry about using routing with DHCPv6
One thing to keep in mind is that Dibbler did note interoperability with ISC DHCP software. So, some efforts have resulted in some multi-vendor compatability, even if official standards have not yet become very solidified.
- Reserved resources
- IANA port reservartions shows TCP port 547 and UDP port 547 are reserved for dhcpv6-server, and TCP port 546 and UDP port 546 are reserved for dhcpv6-client.
- [#dhcp6srv]: Initial setup of implementations (of DHCPv6 servers)
(This is part of a larger category of information about DHCPv6.)
http://ipv6int.net/software/index.html#dhcpv6 has some info on implementations.
Additionally, this guide has some info:
- ISC DHCP 4+
Note: At the time of this writing, shortly after OpenBSD 5.0's release, the downloadable package for ISC DHCP in OpenBSD's packages system was still using code that originated from an older version of ISC DHCP (3.x, or perhaps even 2.x), which does not support DHCPv6. So, before struggling with trying to force working IPv6 support, check that the version is based on code from an ISC DHCP version number of at least 4. An ISC blog entry about using routing with DHCPv6 states about ISC DHCP, “Note that versions from the 3.x family do not support DHCPv6 and cannot be used for this purpose.”
ISC DHCP 4.x supports both DHCP for IPv4 and also DHCPv6. The Linux Documentation Project page about Linux IPV6 ISC DHCP says, “Note that currently, the ISC DHCP server can only serve IPv4 or IPv6, means you have to start the daemon twice (for IPv6 with option “
-”) to support both protocols.” (This is also clear from text in the product's “man pages”.)
- About the OMAPI package
With OpenBSD, there may be a package called isc-dhcp-server and also a package named isc-dhcp-omapi which (according to OpenBSD 4.6 package info for isc-dhcp-omapi) “is currently used by the ISC DHCP server.” This OMAPI software is not the server itself, nor a standard DHCPv6 client, but is a tool that is used to modify how the server operates. A computer (presumably the server, or a client) may be able to install the package called isc-dhcp-omapi which contains server configuration tools (which may specify a server, and so presumably works on a remote server). This package does not the DHCP server nor DCHP client). This OMAPI package is unnecessary for simply getting DHCPv6 to operate.
- Some further overview/documentation resources/notes
(See commentary by Linux DHCPv6).
The Linux Documentation Project page about Linux IPV6 ISC DHCP: Simple configuration shows a sample configuration.
ISC document: ISC DHCP and IPv6 - the DHCPv6 story (previously located at http://www.isc.org/community/blog/201104/isc-dhcp-and-ipv6-dhcpv6-story but no longer at that location) may be historical (describing creating the earliest support for DHCPv6).
(Possible reference: may be good, or perhaps not: An example config found on the net)
Side note: ISC's dhcp-script runs: “
). It also may overwrite
- Steps for installation/configuration
- Initial setup
This guide was written after router advertisements were already working well.
- Licensing :)
- Happily, the ISC license is extremely similar to the BSD license, and the OpenBSD Copyright Policy page even states (about the ISC license), “This is the preferred license for new code”.
Note for OpenBSD: The customized version of ISC DHCP that comes with OpenBSD is not suitable for IPv6 (when last checked... that appeared to be true as of OpenBSD 5.3. So, upgrade it. (OpenBSD ports information: ISC DHCP package).
If DHCPd is being used for DHCP/IPv4, stopping DHCP/IPv4 seems like a prudent move (although it is probably actually unnecessary in this case.)
If there is an OMAPI flavor, note that the OMAPI version may be a set of server configuration software, and does not contain either the server nor the client.
Details on installation will depend on the software package management system: see: software installation.
- Path notes
These instructions are designed for use with OpenBSD. With OpenBSD, at the time of this writing, there is a built-in variation of ISC DHCP. (According to Kliment Andreev's blog of ISC DHCP server on OpenBSD 4.2, “The original DHCP server that is provided with OpenBSD is a custom build based on ISC DHCP v2.”) Adding ISC DHCP to the already-existing DHCP/IPv4 software can work fine: they can co-exist and even be running at the same time (with ISC DHCP version 4 handling DHCPv6 and the OpenBSD variation supporting DHCP/IPv4). However, one thing to keep in mind:
Be careful with the paths!
By default, the package's manual pages may be used, while by default, the built-in executables may be used. (This means that the manual pages will, by default, not match the executable file.)
These instructions help to take care of the issue for OpenBSD. However, the paths shown in these instructions will probably not work with other operating systems. In many cases, other operating systems might come with ISC DHCP built-in, and so paths for executable files and man pages might be completely unnecessary.
- Manual pages
will show available manual pages for that specific topic, along with paths. Using
which is the same thing as running
will show topics containing the requested substring, and shows two copies of the man pages.
After installing ISC DHCP, if you want to see OpenBSD's manual page, use
... or check it out online (OpenBSD manual page for
). The OpenBSD package for ISC DHCP may be titled “OpenBSD System Manager's Manual”, which does not easily identify which version of the man page is being seen. The manual page bundled with OpenBSD does end with a section titled “BUGS”, which does not seem to be true for the manual bundled with the ISC DHCP package.
will show the package's manual page, which will be the default when simply running:
- Configuration file
- Modifying the configuration file
There appears to be a possibility of just using one configuration file for both DHCPv6 and DHCP/IPv4. However, even if having both protocols be handled by the same configuration file might be usable, using a separate configuration file just makes more sense for the current time. The reason is because DHCPv6 needs to be run using a separate process, so there's little reason to try to cram everything in the config file, and keeping DHCPv6 stuff out of the config file used for IPv4 may lead to more compatability with various versions of DHCP servers, including OpenBSD's variant which is an update to ISC DHCP v2.
The Linux Documentation Project: hints for ISC DHCP uses /etc/dhcp/dhcpd6.conf as an example file.
(The following is meant to be fairly similar to OpenBSD's example file from the section on DHCP/IPv4 servers. The Linux Documentation Project: hints for ISC DHCP was probably also have been a resource used to help convert this to a format usable for ISC DHCP's DHCPv6 support.)
The above filename is simply an example. If there are multiple NICs with different configurations, then placing a NIC identifier/name, as part of the filename, makes sense.
Notes: make sure to update the addresses on the
subnetline and the
rangeline. On the
rangeline, both starting address and the ending address need to be in the subnet that is specified on the
The values for the
come from usable DNS servers and the FEC0:0:0:FFFF/126 block, and so might not need to be customized on some networks (at least for initial testing), but the
one should be removed if a privately-run server has not been set up at that address. (Eventually a more ideal configuration will be to have the IPv6 addresses should be pointing to privately-run servers. However, that is likely unneeded for initial testing, particularly if the privately-run DNS servers have not been deployed yet.)
Do update the value of the domain. (Run
to get a reminder of what the desired domain will be.)
- Notes on the idea of supporting routing
Notice that this shows a range, and DNS information. The other key piece of information that is usually distributed over DHCP/IPv4 is the “default gateway”, (which is basic routing information).
Well, that was common with DHCP/IPv4. With DHCPv6, this may be a different story.
See Routing information in DHCPv6 for further details. (To summarize, “The recommendation being made as of September 2013 is to re-visit this topic at a later time”. Meanwhile, routing can be performed using an approach other than DHCPv6. Mainly, using router advertisements.)
- Testing the configuration file
Note: These paths are designed for OpenBSD, and will likely vary for other platforms. Users of other platforms may just want to try starting the command lines with
but the exact process with vary between different operating systems. Simply trying to run
will probably not work as well with OpenBSD.
(The general process is going to be quite a bit like Testing the configuration file (before running the DHCP/IPv4 server).)
To use the server from the package, run the following command. (Naturally, customize that configuration file's path as needed.)
-q -4 -t -cf
Hopefully that will return zero (“
”). If it returns a value of one (“
”), be sure to check out the contents at the end of /var/log/messages (or perhaps the /var/log/daemon file).
If any changes are needed, run
before re-running the test. (The point to running
is to show a time-stamp. Make a temporary but accessible note of the time that it shows.) That way, if there appear to be troubles, the log entries can be compared to that time-stamp to help separate out older log entries from newer ones.
- Running the software
The leases file for ISC DHCP's DHCPv6 support needs to be a file that exists, but the file probably does not exist by default. (So, make it.)
Also, know the name of the NIC so that it may be used on the command line. (Specifying the NIC on the command line might not be required.)
Once the configuration file seems okay and the leases file exists, then go ahead and try running the software:
-q -4 -cf
(Side note: if DHCRelay is being used, the executable file to run may be
Recommended: If this is the first time running the software, then after getting the command prompt back, verify that the software is still running. (See: listing running software.) Also check out the log file(s) (probably /var/log/daemon but /var/log/messages is another possibility).
- Testing the server
Note: Clients might ignore the DHCPv6 server if the router advertisements tell them to, so adjust the router advertisements to specify that DHCPv6 should be getting used.
Have a client try to contact the DHCPv6 server. See: DHCPv6 clients.
- [#wdhcp6s]: WIDE-DHCPv6
WIDE-DHCPv6 package comes with WIDE-DHCPv6 client software, server software, and relay software. (This section of text focuses on the server software.) Distributions of software packages may also have a package named WIDE-DHCP which is an entirely different software package meant for IPv4.
- Example file(s)
In OpenBSD, some of the files that are installed with this include /usr/local/share/examples/wide-dhcpv6/dhcp6s.conf.sample (and /usr/local/share/examples/wide-dhcpv6/dhcp6c.conf.sample for the client).
As can be seen by viewing the online OpenBSD CVSWeb patch file for dhcp6s.conf.sample (version 22.214.171.124), the example file shows a DUID with 6 pairs of colon-sepearted hexadecimal digits: This implies that an EUI48/MAC can be specified as a DUID. In reality, the DUID does not need to match an EUI48/MAC address (and it is not recommended to worry about trying to make the DUID batch an EUI48/MAC address). This is discussed further in the section about handling DHCPv6 reservations.
- Usage in OpenBSD
- Despite OpenBSD coming with some sort of DHCP (for IPv4) server which (from the man page) may be its own variant (though it seems a bit related to ISC, there is a separate package for ISC's DHCP), and despite OpenBSD coming with KAME, it may be that OpenBSD does not come with a DHCPv6 server built-in. However, there is a package called wide-dhcpv6 (which is different than the package called wide-dhcp which is for IPv4).
- Usage in Debian
Archive.orgarchive of “Native PPP IPv6 in Debian” blog entry is about PPP and includes information about WIDE. Of particular note: “When you install the WIDE DHCPv6 client it starts automatically, with an” (sic) “non-useful config.” Be sure to stop that software if the only desire is to be running the server.
(The “Summary tab”, before overwriting itself with the project feed, notes this is for “All POSIX (Linux/BSD/Unix-like OSes)”.) OpenPorts.se page related to WIDE-DHCPv6 notes this “was originally developed by the KAME project, but is now maintained separately.”
OpenPorts.se page for WIDE-DHCPIPv6 notes, “NOTICE: This package no longer exists in Ports”. (Perhaps this is/was just a temporary problem with OpenPorts.se? A note was made that other packages/categories seem to be missing as well. This may need to be re-visited...)
- A bug?
Michigan Tech DHCPv6 example notes, “It should be noted that the WIDE-DHCPv6 server fails to authenticate some or all relayed requests. Whether the problem lies in
, or my understanding of authentication configuration is unknown at this time.”
Installation isn't really particularly special: install it just like other software. However, beware that the name of the package should start with something like wide-dhcpv6. There may also be a similar package named wide-dhcp which contains server software for IPv4, not IPv6.
- Getting a client's DHCPv6 UID
This is dependent on the DHCPv6 client being used. Information is available about getting the DHCPv6 UID used by a WIDE-DHCPv6's DHCPv6 client.
- Example server configuration
Although this software does support signed messages, this guide currently does not start out by covering that process. The initial goal is simply to show this software working (with unsigned messages). Here are some of the basics.
The first command (
) will only run if the file exists. The second command (
) will only run if the file still does not exist. Either way, the file will start to be edited.
There is an available ability to use:
This simple guide does not use that statement, as there seems to be no need. Separating out the information would likley only add to the difficulty of being able to quickly understand the configuration. However, know that the ability is there if it would be useful.
- Global information
Set some name server(s). e.g.: a not-fully-standardized usage: “Well-known” (site-local) DNS servers, and another example IPv6 site (matching the reference shown by /usr/local/share/examples/wide-dhcpv6/dhcp6s.conf.sample from OpenBSD's WIDE-DHCPv6 package), as follows:
To see more available servers, check out the available information about external publicly available DNS servers.
- Defining information for most hosts
- Gather the required information
What addresses re going to be handed out? What is the name of the available NIC that addresses will be handed out on? Though not technically required just for functionality, good practice also states to know what the addresses will be used for, so that the pool of addresses may be appropriately named.
- Define a pool
Pretty straightforward. Here is an example defining two pools.
- Configure responses on a NIC to use an existing pool
(Note: the order of these instructions (making a pool, and then referencing it) does not seem to be required: example documentation has been known to show a reference to the pool being made before the pool's specification.
- DHCPv6 reservations
A DUID needs to be specified. This DUID is a series of colon-separated pairs of hexadecimal digits. They can vary in length. (There are some patterns/specifications to follow when creating a DUID, and the length going to be used may vary depending a bit on which specification is being followed.) (For more information about a DUID, see handling DHCPv6 reservations. For more information about getting a DUID from a client using this same software suite, see getting a Wide-DHCPv6 “DUID”.)
The name of the provided system can effectly be viewed as a comment. The software only uses it to place as a string in log files. That said, for the sake of easily readable log files (and easy understanding of the configuration file later), it makes sense to put a sensible value there.
- Running the server
Not all of those parameters are required. The “
-c” is specifying the default value, so feel free to leave that off (particularly if typing this manually). The
-Pis not technically required just for the program to run, although using PID files is generally a good practice to help ease automation in the future.
- [#dibbler]: Dibbler
For Linux and Microsoft Windows. As of November 13, 2011, Dibbler 0.8.1. Release Candidate 1 added support for BSD (OpenBSD, FreeBSD, and NetBSD), and improved support for Mac OS X.
“This project was started in 2003 as master thesis”. It, therefore, probably should not be too surprising to read “Due to work on my Ph.D, the Dibbler project is in the maintenance mode. Active development and non-critical bug fixing is on hold, until I finish my dissertation. Sorry.” (Hmm, that message does not seem to be on the page anymore. The February 11, 2011 update notes the author's multi-“year struggle to complete my Ph.D. is finally over.”)
GPLv2 (“not v2 or later”, as noted by 2008-08-31 update).
- Built into Windows Vista and later
- Microsoft Windows DHCP Team Blog
- [#lnxdhcv6]: Linux DHCPv6
- http://fedorahosted.org/dhcpv6/ (redirected to by dhcpv6.sf.net ) said: “No new development will be happening on this project. dhcpv6 has been obsoleted by ISC dhcp version 4.1.0 and later.” The Sept 22, 2009 news goes on to say, “as for new development, the project is shut down.” (Note: OpenBSD 4.6, releaed October 18, 2009, was released after that announcement yet included ISC DHCP 3.1.1, not 4.1.0 or later. It is possible the packages were simply frozen too early for that OpenBSD release, or it is possible that version 4.1.0 was intentionally not included for some reason. It may be interesting to see what happens with the release of OpenBSD 4.7. It is not necessarily certain whether ISC DHCP 3.1.1 supports DHCPv6 or not.)
- It would not be surprising if some DHCP (for IPv4) servers, such as dnsmasq, end up supporting DHCPv6.