Re: [dhcwg] SLAAC and DDNS

[<Greg.Rabil at ins.com>]

Bernie,
> 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.

I was more concerned about the case where the client and server support the "lightweight", stateless DHCPv6 protocol only.

David,

> 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.

I suppose that's true, so the client would have to include an option telling the server about its IP address(es) in the Info-Request message.

> 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.

Yes, I agree that it would need to be MUST to include client id.

> 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.

If the client-id is required, then the risk would be the same as with stateful DHCPv6 and the FQDN option, right?
 
Greg