====== Frequently Asked Questions ====== === What is DHCP? === //[Extract from RFC 2131]// ''The Dynamic Host Configuration Protocol (DHCP) provides configuration parameters to Internet hosts. DHCP consists of two components: a protocol for delivering host-specific configuration parameters from a DHCP server to a host and a mechanism for allocation of network addresses to hosts.'' === Where can I find information about the DHCP protocol? === The first source of information are the RFCs themselves. See below about RFC compliance. I suggest an excellent book on DHCP: The DHCP Handbook (2nd edition), Ralph Droms and Ted Lemon. === Is DHCP4Java free to use? === Yes. It is provided under L-GPL licence, which means that you can you it in any code, open-source or not. === What is a DHCP static/dynamic/algorithmic server? === There are three basic ways to allocate IP addresses to clients: static (pre-configured client by client), dynamic (allocated from address pools), algorithmic (calculated from data in the request - often taken from option 82). **Static address allocation** is the simplest server to implement. It requires that every client is pre-provisioned in the server. Each client is always given the same address (hopefully) different from one client to another. However this allocation scheme is not very flexible and generates high administrative work to network administrators. It is still used for equipment needing fixed IP addresses such as printers... **Dynamic address allocation** allows automatic address allocation generally on a first-connected first-served scheme. Leases are limited in time to allow address reuse if a client is permanently disconnected. This scheme requires persistence on the server side which raises some availability issues. Such servers should also be aware of denial of service caused by the exhaustion of all available addresses from a bogus/malicious client. **Algorithmic address allocation** is a mix of the two previous schemes. It can be seen as an "automatic static server" in which addresses are not manually preallocated, but calculated on the fly with data taken from the request. This is generally used by ISPs (cable or DSL) to assign a fixed IP address to each physical line (cable or phone) allocated in sequence. This is done by analysing the option 82 added by the DHCP relay which marks the id of the physical line used. Simple calculation can be done to assign an IP address based on the subnet and line-id information. This scheme is quite easy to implement but has two drawbacks: it allows only 1 IP address per physical line, and it needs pre-allocation of all possible IP addresses even if there is no connected client. For this later reason, it is often limited to private non-routable IP addresses. DHCP4Java will first support **static** and **algorithmic** allocation. Fully **dynamic** is for future plans. === Why using Java for a DHCP Server === Traditional DHCP Server implementations are built using C or C++. It appeared quickly that such servers could be developed as well using higher productivity languages such as PERL or Java. Java offers unique opportunities to server development such as: easy multi-threading/multi-CPU/mutli-core support, wide variety of connectivity APIs to databases through JDBC, wide community of developers... === Are there limitations introduced by Java? === Very few. The UdpDatagram API does not allow to send datagrams to 255.255.255.255 IP address (broadcast) using Ethernet unicast to a specific MAC address. This means that DHCPOFFER are always broadcast on the network, as if the "Broadcast bit" in client requests is always set. This has no impact on client, it only generates little additionnal traffic on the link, which is totally negligible on modern networks. It is not possible to develop a DHCP Client in pure Java, due to a lack of API to read the MAC address of the network link. You can still develop a test Client or use system specific command/API. === What version of Java is supported? === DHCP4Java requires Java5 (J2SE or J2EE), aka Java 1.5. I switched to Java5 early in the development stage and I will not go back (do not ask!). Java5 simplifies the code dramatically thanks to generics, static imports, boxing/unboxing and concurrency libraries. This API will be mainly used to develop new servers, and I cannot see any use case of using this API in existing code prior to Java5. === Does DHCP4Java support J2ME? === Not currently. However it should be relatively easy to simplify the API for a J2ME version. Let me know if there is such a need. === Can DHCP4Java be used to implement a DHCP Client? === Yes at the protocol level. No for Java implementation reasons. There is no standard way in Java to retrieve the MAC address of a network interface. This requires non-portable system specific calls. //By the way, if you some way to develop a 100% Java DHCP client, please let me know.// === Do you provide a DHCP Client? === No, please so above about the Java limitations. You can find sample code for DHCP client in the examples package, but it is merely for server testing purpose. === Do you provide a DHCP Relay? === Not currently. First option would be to develop an independant relay such as the one from ISC. My plans are to provide a "proxy-mode" to the DHCP Server to allow DHCP requests relaying. This mode would be similar to the mod_proxy module for the Apache server. === Do you provide a BOOTP client or server? === No. BOOTP is supported only at the API level, but largely untested. === Do you support IPv6? === No. DHCP4Java only supports IPv4. DHCP for IPv6 is a totally different story, maybe someday? === Does Java offer enough performance compared to C? === Yes. Comparative tests are planned, but Java performance is largely enough even for high volume DHCP servers, see right below. === How fast is DHCP4Java? === The API has been designed to be fast enough to support very large scale DHCP servers for millions of customers. Formal performance tests are planned. However, preliminary tests show that the API is able to handle more than 10.000 req/s on a simple Laptop (Pentium-M 1.5GHz) with 512MB memory. My original API was implemented in PERL, but I decided to switch to Java to broaden the potential developers audience. Porting the API from PERL to Java showed a ~10x performance boost with additionnal support for multi-threading. === Can I use DHCP4Java to implement a BOOTP server? === Yes. DHCP4Java fully support BOOTP. However my first goal is to develop a DHCP server. BOOTP code is largelly untested. Use it at your own risk. Feedback and bug reports would be appreciated. === Which RFCs are supported by DHCP4Java === Our design objectives are to be totally conformant to RFC regarding BOOTP/DHCP. Any non-conformant feature will be clearly documented and argumented. This may include special work-arounds for client bugs or future DHCP feautures not totally normalized yet. This includes the following RFC: |[[http://www.ietf.org/rfc/rfc1534.txt|RFC 1534]]:|Interoperation Between DHCP and BOOTP | |[[http://www.ietf.org/rfc/rfc2131.txt|RFC 2131]]:|Dynamic Host Configuration Protocol, Obsoletes RFC 1541| |[[http://www.ietf.org/rfc/rfc2132.txt|RFC 2132]]:|DHCP Options and BOOTP Vendor Extensions| |[[http://www.ietf.org/rfc/rfc2241.txt|RFC 2241]]:|DHCP Options for Novell Directory Services| |[[http://www.ietf.org/rfc/rfc2242.txt|RFC 2242]]:|NetWare/IP Domain Name and Information| |[[http://www.ietf.org/rfc/rfc2855.txt|RFC 2855]]:|DHCP for IEEE 1394| |[[http://www.ietf.org/rfc/rfc2937.txt|RFC 2937]]:|The Name Service Search Option for DHCP| |[[http://www.ietf.org/rfc/rfc3004.txt|RFC 3004]]:|The User Class Option for DHCP| |[[http://www.ietf.org/rfc/rfc3011.txt|RFC 3011]]:|The IPv4 Subnet Selection Option for DHCP | |[[http://www.ietf.org/rfc/rfc3046.txt|RFC 3046]]:|DHCP Relay Agent Information Option | |[[http://www.ietf.org/rfc/rfc3396.txt|RFC 3396]]:|Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4) [//not yet implemented//]| |[[http://www.ietf.org/rfc/rfc3397.txt|RFC 3397]]:|Dynamic Host Configuration Protocol (DHCP) Domain Search Option| |[[http://www.ietf.org/rfc/rfc3442.txt|RFC 3442]]:|The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4| |[[http://www.ietf.org/rfc/rfc3679.txt|RFC 3679]]:|Unused Dynamic Host Configuration Protocol (DHCP) Option Codes| |[[http://www.ietf.org/rfc/rfc3942.txt|RFC 3942]]:|Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options| |[[http://www.ietf.org/rfc/rfc4388.txt|RFC 4388]]:|Dynamic Host Configuration Protocol (DHCP) Leasequery| === Are there some non conformance to RFCs? === RFC 2131 - section 4.1 - the behaviour of the server can not be totally conformant due to Java limitation. [...] If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is set, then the server broadcasts DHCPOFFER and DHCPACK messages to 0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and 'ciaddr' is zero, then . [...] t is not possible to unicast UDP datagrams to hardware addresses using the Java API. Only unicast to IP addresses are supported. As a side effect, servers act always as if the broadcast bit is always set. This has no functional impact on clients and negligible impact on network traffic. === Who uses DHCP4Java? === [Coming soon]