on multi-interface machines if configured to listen on only one of the
interfaces.)
+We have reports of Windows XP clients having difficutly retrieving
+addresses from a server running on an AIX machine. This issue
+was traced to the client requiring messages be sent to the all ones
+broadcast address (255.255.255.255) while the AIX server was sending
+to 192.168.0.255.
+
+You may be able to solve this by including a relay between the client
+and server with the relay configured to use a broadcast of all-ones.
+
+A second option that worked for AIX 5.1 but doesn't seem to work for
+AIX 5.3 was to:
+ create a host file entry for all-ones (255.255.255.255)
+and then add a route:
+ route add -host all-ones -interface <local-ip-address>
+
The ISC DHCP distribution does not include a dhclient-script for AIX--
AIX comes with a DHCP client. Contribution of a working dhclient-script
for AIX would be welcome.
+
MacOS X
The MacOS X system uses a TCP/IP stack derived from FreeBSD with a
.\"
.\" Project: DHCP
.\" File: dhcpctl.3
-.\" RCSId: $Id: dhcpctl.3,v 1.8 2009/11/24 02:06:56 sar Exp $
+.\" RCSId: $Id: dhcpctl.3,v 1.9 2011/04/25 23:43:16 sar Exp $
.\"
+.\" Copyright (c) 2011 by Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (c) 2004,2009 by Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (c) 2000-2003 by Internet Software Consortium
.\" Copyright (c) 2000 Nominum, Inc.
The following program will connect to the DHCP server running on the local
host and will get the details of the existing lease for IP address
10.0.0.101. It will then print out the time the lease is due to expire. Note
-that most error checking has been ommitted for brevity.
+that most error checking has been ommitted for brevity.
.Bd -literal -offset indent
-#include <stdarg.h>
#include <sys/time.h>
-#include <sys/socket.h>
#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <stdarg.h>
+
+#include <sys/socket.h>
#include <netinet/in.h>
+#include <arpa/inet.h>
-#include <isc/result.h>
-#include <dhcpctl/dhcpctl.h>
+#include "omapip/result.h"
+#include "dhcpctl.h"
int main (int argc, char **argv) {
dhcpctl_data_string ipaddrstring = NULL;
.\" dhcpd.conf.5
.\"
-.\" Copyright (c) 2004-2010 by Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (c) 2004-2011 by Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (c) 1996-2003 by Internet Software Consortium
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" Support and other services are available for ISC products - see
.\" https://www.isc.org for more information or to learn more about ISC.
.\"
-.\" $Id: dhcpd.conf.5,v 1.108 2010/07/02 23:09:15 sar Exp $
+.\" $Id: dhcpd.conf.5,v 1.109 2011/04/25 23:43:16 sar Exp $
.\"
.TH dhcpd.conf 5
.SH NAME
accept updates from the DHCP server.
.PP
Two DNS update schemes are currently implemented, and another is
-planned. The two that are currently available are the ad-hoc DNS
+planned. The two that are currently implemented are the ad-hoc DNS
update mode and the interim DHCP-DNS interaction draft update mode.
-If and when the DHCP-DNS interaction draft and the DHCID draft make it
-through the IETF standards process, there will be a third mode, which
-will be the standard DNS update method. The DHCP server must be
-configured to use one of the two currently-supported methods, or not
-to do dns updates. This can be done with the
+In the future we plan to add a third mode which will be the standard
+DNS update method based on the RFCS for DHCP-DNS interaction and DHCID
+The DHCP server must be configured to use one of the two
+currently-supported methods, or not to do dns updates.
+This can be done with the
.I ddns-update-style
configuration parameter.
.SH THE AD-HOC DNS UPDATE SCHEME
A and PTR records.
.SH THE INTERIM DNS UPDATE SCHEME
The interim DNS update scheme operates mostly according to several
-drafts that are being considered by the IETF and are expected to
-become standards, but are not yet standards, and may not be
-standardized exactly as currently proposed. These are:
+drafts considered by the IETF. While the drafts have since become
+RFCs the code was written before they were finalized and there are
+some differences between our code and the final RFCs. We plan to
+update our code, probably adding a standard DNS update option, at
+some time. The basic framework is similar with the main material
+difference being that a DHCID RR was assigned in the RFCs whereas
+our code continues to use an experimental TXT record. The format
+of the TXT record bears a resemblance to the DHCID RR but it is not
+equivalent (MD5 vs SHA1, field length differences etc).
+The standard RFCs are:
+.PP
+.nf
+.ce 3
+RFC 4701 (updated by RF5494)
+RFC 4702
+RFC 4703
+.fi
+.PP
+And the corresponding drafts were:
.PP
.nf
.ce 3
-draft-ietf-dhc-ddns-resolution-??.txt
-draft-ietf-dhc-fqdn-option-??.txt
draft-ietf-dnsext-dhcid-rr-??.txt
+draft-ietf-dhc-fqdn-option-??.txt
+draft-ietf-dhc-ddns-resolution-??.txt
.fi
.PP
Because our implementation is slightly different than the standard, we
chooses a new name.
.PP
The interim DNS update scheme is called interim for two reasons.
-First, it does not quite follow the drafts. The current versions of
-the drafts call for a new DHCID RRtype, but this is not yet
-available. The interim DNS update scheme uses a TXT record
-instead. Also, the existing ddns-resolution draft calls for the DHCP
-server to put a DHCID RR on the PTR record, but the \fIinterim\fR
-update method does not do this. It is our position that this is not
-useful, and we are working with the author in hopes of removing it
-from the next version of the draft, or better understanding why it is
-considered useful.
+First, it does not quite follow the RFCs. The RFCs call for a
+new DHCID RRtype while he interim DNS update scheme uses a TXT record.
+The ddns-resolution draft cllaed for the DHCP server to put a DHCID RR
+on the PTR record, but the \fIinterim\fR update method does not do this.
+In the final RFC this requirement was relaxed such that a server may
+add a DHCID RR to the PTR record.
.PP
In addition to these differences, the server also does not update very
aggressively. Because each DNS update involves a round trip to the
projects / thirdparty / dhcp.git / commitdiff
