IETF Logo Mail Archive

[dhcwg] SLAAC and DDNS

<Greg.Rabil@ins.com> Fri, 27 February 2009 16:01 UTC

Return-Path: <Greg.Rabil@ins.com>
X-Original-To: dhcwg@core3.amsl.com
Delivered-To: dhcwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52F1B28C1DB for <dhcwg@core3.amsl.com>; Fri, 27 Feb 2009 08:01:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwQnOlmZfNHs for <dhcwg@core3.amsl.com>; Fri, 27 Feb 2009 08:01:15 -0800 (PST)
Received: from mailmx.ins.com (mailmx.ins.com [198.134.150.13]) by core3.amsl.com (Postfix) with ESMTP id 8E4F13A68D5 for <dhcwg@ietf.org>; Fri, 27 Feb 2009 08:01:15 -0800 (PST)
Received: from usemp11.ins.com (usemp11.ins.com [172.18.67.64]) by usppp06 (8.14.3/8.14.3) with ESMTP id n1RG1b8g028830 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <dhcwg@ietf.org>; Fri, 27 Feb 2009 10:01:37 -0600
Received: from usemp11.ins.com ([172.18.67.64]) by usemp11.ins.com ([172.18.67.64]) with mapi; Fri, 27 Feb 2009 10:01:37 -0600
From: Greg.Rabil@ins.com
To: dhcwg@ietf.org
Date: Fri, 27 Feb 2009 10:01:34 -0600
Thread-Topic: SLAAC and DDNS
Thread-Index: AcmY7Z/kChBlN2OUTia1Z74+qGxTswAAeaUwAABjhwA=
Message-ID: <1E4636828B4AD841900A31378A9FE3CD01132116C7@usemp11.ins.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-02-27_14:2009-02-26, 2009-02-27, 2009-02-27 signatures=0
Subject: [dhcwg] SLAAC and DDNS
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Feb 2009 16:01:16 -0000

There has been some discussions on the ISC DHCP mailing list about folks wanting to perform DDNS in an environment where clients are doing stateless address auto-config.  One solution offered is that the client perform the update after it gets the DNS server(s) and domain(s) from a stateless DHCPv6 server.

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.

Is there any interest in this approach?  If so, I would consider writing a draft to include the FQDN option in Info-Request messages.

Regards,
Greg Rabil

v2.23.0 | Report a Bug | By Email