[dhcwg] Pre-determining DUID

Jarrod Johnson <jarrod.b.johnson@gmail.com> Sat, 10 October 2009 01:08 UTC

Return-Path: <jarrod.b.johnson@gmail.com>
X-Original-To: dhcwg@core3.amsl.com
Delivered-To: dhcwg@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 2D41828B23E for <dhcwg@core3.amsl.com>; Fri, 9 Oct 2009 18:08:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id QjzPXI8s9ACk for <dhcwg@core3.amsl.com>; Fri, 9 Oct 2009 18:08:33 -0700 (PDT)
Received: from mail-yw0-f189.google.com (mail-yw0-f189.google.com []) by core3.amsl.com (Postfix) with ESMTP id 3851D28C1F8 for <dhcwg@ietf.org>; Fri, 9 Oct 2009 18:08:33 -0700 (PDT)
Received: by ywh27 with SMTP id 27so645588ywh.31 for <dhcwg@ietf.org>; Fri, 09 Oct 2009 18:10:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=EaPKGEyOuAq5k4GJJuF55rfLhYhGCY0pbS1daaGhnCY=; b=mYboTLM5nHAGki7uIp/IaLfRAsVnf9SXn7KcIlrwVrtkLa5d/hD0kF2LL5oI6BSyW4 kiE7mVGj+NjZ+gEuUquY2ZKPA9/HVMO5zMw1bghkwxZd1A+Q4d6y0BN7ydSEPtlvzgEJ hyix6+j4L7SHir5rHCndFu+gJMyJZVE+TIb4E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=PhhysJemAF4Yq03ncxwyLiUcdYsvZ6Bnh0uPzL6+uMetlC4q9+IoWzjrNMC+YxD5UW Qc5wBt3cXUrhyjFS/uKcJTrpKpk1NQPOkDtoXzPb1e0nc4lbip+mw1/z5nT98BMgCuOd aEznacz9EUhY1K9F2vkJqp5Yrd52q0PgT6Gfg=
MIME-Version: 1.0
Received: by with SMTP id j20mr5911705yba.42.1255137015312; Fri, 09 Oct 2009 18:10:15 -0700 (PDT)
Date: Fri, 09 Oct 2009 21:10:15 -0400
Message-ID: <fab4e42a0910091810j71fcabd8h12d992be6d28d320@mail.gmail.com>
From: Jarrod Johnson <jarrod.b.johnson@gmail.com>
To: dhcwg@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
X-Mailman-Approved-At: Sat, 10 Oct 2009 13:23:05 -0700
Subject: [dhcwg] Pre-determining DUID
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: Sat, 10 Oct 2009 01:09:08 -0000

I was trying to comb through to see if in the generic DHCPv6 space
that any alternative to the current DUIDs would be provided to more
closely mimic capabilities in DHCPv4.  I've seen a lot of controversy
and a suggestion that a draft be put together, but I can't seem to
find any draft.  I know I am digging up a discussion that has occurred
time and time again, but I have not been able to find any constructive
conclusions that are useful to me so far.

I am fully aware of the aims of trying to use a different strategy of
DHCPv6 for many use cases, but much of my life in networking relies on
centrally managing and pre-configuring a host's network identity
before it turns on.  It also depends on the address staying with the
underlying entity rather than the OS image that runs on top of it.  As
a common specific instance of the previous point, it depends upon a
coherent, consistent identity to be maintained during firmware
bootstrap (currently, no IPv6 capable boot firmware, but I see there
is a draft discussing that) and the resultant operating system.  The
current DUID strategies do not provide for a mechanism that is even
likely to be similar between those two largely uncoordinated pieces of
code running on the same entity.

One thing I've seen suggested is a mechanism by which the networking
'edge' would tag dhcp packets to key off of that, the problem there
being that I generally must deal with 'edge' devices presenting
multiple mac addresses on the same port, rendering that proposed
mechanism insufficient.

I've considered potentially using the stateless addressing, but two
problems that occur are that DNS zone updates would have to be
manipulated in a global scope which takes more time than a DHCP
binding change in my segments and, more importantly,  I either must
choose the variant that shares the hardware address in the global
namespace or use the privacy addresses which brings me back to square
one where I can't centrally manage network identity mapping between
layer 2 and layer 3.

With the current circumstances, the best I can do makes an IPv4
provisioning network on my segments a prerequisite for IPv6 function.
Essentially, I would leverage the semantics of IPv4 to bootstrap the
environment identities and deploy OS, and at the same time, feed down
a static DUID for that host to achieve persistence across deployment
actions.  I'm not particularly excited about a long-term strategy that
requires IPv4 to function simply because a particular semantic was
given no allowance in the IPv6 generation of protocols.  It's also a
minus that I have to be pretty hands on for every platform I deploy.

I wanted to know if I missed something in the drafts and it was there
or else how it may be possible to add a standard field to store the
traditional hw-type,hw-addr data in the DHCPv6 payload in addition to
the DUID today.