On-going work on DHCP project : RFC4361 support

[David W. Hankins]

On Mon, Mar 15, 2010 at 04:25:32PM +0100, Rene Garcia wrote:
>   Here is some additional information on Thomas'work : the stored  DHCID 
> in DNS servers will change and therefore upgrading to this new behaviour 
> will need a lot of work to migrate old emulated TXT DHCID to new ones. 
> That's why I aked him to add support for real DHCID RRs in DNS as ISC BIND 
> 9.5+ seems to handle them.

Migrating to the DHCID RR is definitely something we want to do.

This is not something we have done ourselves because to do so we feel
we need to present the operators of current server infrastructure with
a migration plan.

The problem essentially is that I haven't been able to come up with a
plan that I like, so I haven't started work myself.

Either a startup condition that traverses the lease database and
converts/reassigns from TXT to DHCID, and then proceeds with DHCID
from there out, or a command line tool or script that performs a
conversion is one set of ideas I more or less favor but am not
convinced of yet.

We've considered the idea of using both DHCID and TXT for a migration
period, but do not like the plan.  It multiplies the number of DNS
requests the server must send by quite a lot potentially.  The problem
with not supporting this option is that server operatores will be
required to upgrade all DHCP servers to consistent code - all using the
DHCID - all at once.  This may not be desirable in some networks.

So perhaps the first deliverable of a DHCID RR adoption project could
be describing a workable migration plan and requesting peer review
on dhcp-users. :)


Having the DHCP server start extracting the DHCID contents from a
client identifier for DNS name resolution can be seen as a separate
issue, since we do use DHCID for the TXT record in DHCPv6 operation
today, so for DHCPv4 and the TXT record we can just use the same type
identifier (02 I think it is) as we use in DHCPv6 and move along with
testing.


Switching to a DHCID in 'dhclient' can be a separate issue.  There is
not a significant reverse compatibility problem IMO, because the
client ID is not sent currently, so in DHCPv4 terms the ISC dhclient is
in essence using its 'chaddr' contents as an identifier.

Many DHCP servers (such as ISC DHCP) will allow a client a one-time
migration from chaddr-identification to client-identifier.  And most
operating systems will not start sending a client-identifier in an
ad-hoc maintenance upgrade; such a feature would only be in a feature
release of ISC dhclient and so probably would go into future versions
of OS releases, not maintenance in the dead of night.


So I would encourage the student to look at DHCPv4 client-identifier
DHCID use initially, and perhaps move on to DHCID RR issues as time
or interest permits. :)

The correct place to send patches is to dhcp-suggest at isc.org, which is
a ticketing system.  We look forward to reviewing the submission.


For extra credit, there is another temporary migration problem which
is that many DHCPv4 clients will be IPv6 dual-stack, and either will
still have old-style DHCPv4 client-identifiers, or no
client-identifier at all, and either way present no DHCID.  In this
case how do you permit the IPv4 and IPv6 addresses for the client
to be the same, or do you name the v4 and v6 clients differently as
a workaround (concat(hostname, ".v6", domainname) or similar)?

At the opposite end of the spectrum, there may be DHCPv4 clients that
are dual-stack with stateless address configuration on the IPv6 side.
In this case the client may want its IPv6 address in DNS as well as
its IPv4 address, but doing so again causes it to have problems with
DHCID mismatches, or DNS resolution in general if no DHCID is used
on the IPv6 side (the presence of the AAAA before the A is updated
when a DHCID is not present will keep the A update from being
performed in current sources).

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-workers/attachments/20100318/3cfaf8d1/attachment.bin>