If you're going to have multiple DHCP servers, such as failover pairs,
doing the DNS updates, you need to have those servers agree on how they
will identify the clients. This is not JUST for DNS updates. Failover
partners need to use the same identifiers for clients.
So, this is really not an issue.
The rules are pretty clearly described in the RFC:
For DHCPv4:
1. Use the DUID if the client identifier option is provided by the
client and it is a DUID and the server supports it. This is a new RFC
that is in the RFC-editor queue so no clients and servers yet support
this.
2. Otherwise, use the client identifier option if provided by the
client,
3. Otherwise, use htype and chaddr.
For DHCPv6:
1. Use the DUID of the client.
There really is no mystery here.
- Bernie
-----Original Message-----
From: Jeffrey Hutzelman [mailto:jhutz(_at_)cmu(_dot_)edu]
Sent: Sunday, December 04, 2005 11:43 PM
To: Bernie Volz (volz); Sam Hartman; Mark Stapp (mjs)
Cc: namedroppers(_at_)ops(_dot_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org;
Pekka Savola;
Ted Lemon; iesg(_at_)ietf(_dot_)org; dhcwg(_at_)ietf(_dot_)org; Steven M.
Bellovin;
Jeffrey Hutzelman
Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last
Call:'Resolution of FQDN Conflicts among DHCP Clients' to
Proposed Standard]
On Thursday, December 01, 2005 08:48:10 AM -0500 "Bernie Volz (volz)"
<volz(_at_)cisco(_dot_)com> wrote:
How about we address issue 1 by expanding the DHCID RR type code. We
have 16-bits and we're just using 4 values presently.
There's plenty of
room for future expansion *SHOULD* someone come along and
demand a new
algorithm in the future. I can't see why this would EVER occur since
this really isn't about strong cryptographic protection (we're just
trying to make it non-trivial to find a client's identity
by not storing
it in clear text).
I think that's a good start; in fact, I was going to propose
something very
similar. This solves half the problem; particularly, it
makes it possible
to indicate that some other hash is in use. It does bind the
hash to the
type, rather than allowing them to be specified orthogonally,
but I don't
think that's a major problem. If it ever becomes an issue,
there should be
no problem defining a type where the next 16 bits indicate a
subtype and
the 16 bits after that indicate a hash.
However, it doesn't solve the other half of the problem,
which is present
even without considering changing hash algorithms. The
problem is that for
any given fqdn and DHCP client, there are multiple possible
DHCID RR's; in
particular, one for each type. In order the update mechanism to work
without requiring either an advance query or multiple update
attempts, all
possible updaters must agree in advance on the type in use.
This lack of
negotiation seems problematic to me, even in the absence of
multiple hash
algorithms.
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+(_at_)cmu(_dot_)edu>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf