Re: [dhcwg] SLAAC and DDNS

["Bernie Volz (volz)" <volz at cisco.com>]

Why not have the client do DHCPv6 but have the DHCPv6 server assign the
client the SLAAC address (for what it is worth, CNR's DHCPv6 server
supports this capability). No protocol or client changes (provided the
client already supports DHCPv6 based address assignment - if it doesn't
having it do the Information-Request requires new code anyway). No new
draft to write.

- Bernie 

-----Original Message-----
From: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] On Behalf
Of David W. Hankins
Sent: Friday, February 27, 2009 12:42 PM
To: DHC WG
Subject: Re: [dhcwg] SLAAC and DDNS

On Fri, Feb 27, 2009 at 10:01:34AM -0600, Greg.Rabil at ins.com wrote:
> I think the only drawback to this solution is that doing DDNS updates
from the client makes it difficult to secure the updates using TSIG, for
example.  Distributing the TSIG key(s) to the clients is really not an
option in most cases.  However, there is tremendous benefit to
supporting DDNS in a SLAAC (stateless address auto-config) environment.
One option would be to require client to put their FQDN option in the
Info-Request message sent to a stateless DHCPv6 server.  The source
address of the Info-Request message is the client's SLAAC address, so
the stateless DHCPv6 server would know the IP, and if the FQDN option
were included, it would have enough information to update both the AAAA
and PTR records.  The problem here is that a stateless DHCPv6 server
will not know when the records should be removed from DNS, but stale
records could be cleaned via some other "scavenging" mechanism.

The IPv6 source address of an Info-Request message is more likely a
link-local address, and using this field presumes the client has only
one address.  So you would have to specify that the client MUST select
a source address specifically not in keeping with the usual guidelines
for source address selection.  This isn't impossible, a client can
bind the socket.

You'd also have to specify the client MUST include a client identifier
option so that the server can manufacture a DHCID.  RFC 3315 states
this is a SHOULD for information-request, only a MUST if
authentication is in use.

But, this method raises a security concern.

The client does not have a TSIG key, but by using only the source
IPv6 address field and an FQDN option, it can ask a DHCPv6 server to
perform an update on its behalf.  This mechanism simply extends DHCP
to tunnel through DNS security, to bypass it.  Anyone can send that
packet, and they can ask the DHCP server to update the zone with
whatever contents they might have updated themselves - just limited
to AAAA and DHCID RRs.  This is not very different form simply leaving
the DNS zone wide open, or erecting access control on the DNS zone to
limit RR types.  There is for example a BIND 9 ACL command that
permits systems to update their own PTR records.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins