Re: [dhcwg] Pre-determining DUID

Ted Lemon <> Sun, 18 October 2009 20:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 87CF03A67DA for <>; Sun, 18 Oct 2009 13:55:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.854
X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ar4C-7vYNWuK for <>; Sun, 18 Oct 2009 13:55:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A844C3A67C2 for <>; Sun, 18 Oct 2009 13:54:59 -0700 (PDT)
Received: from source ([]) (using TLSv1) by ([]) with SMTP ID DSNKStuAqd/; Sun, 18 Oct 2009 13:55:12 PDT
Received: from ( []) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by (Postfix) with ESMTP id 41DF01B8282; Sun, 18 Oct 2009 13:55:13 -0700 (PDT)
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 18 Oct 2009 13:55:04 -0700
MIME-Version: 1.0 (Apple Message framework v1076)
Content-Type: text/plain; charset="us-ascii"; format="flowed"; delsp="yes"
From: Ted Lemon <>
In-Reply-To: <20091011002522.GA26560@angus.ind.WPI.EDU>
Date: Sun, 18 Oct 2009 13:55:03 -0700
Content-Transfer-Encoding: 7bit
Message-ID: <>
References: <> <> <20091011002522.GA26560@angus.ind.WPI.EDU>
To: Chuck Anderson <cra@WPI.EDU>
X-Mailer: Apple Mail (2.1076)
Cc: "" <>
Subject: Re: [dhcwg] Pre-determining DUID
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 18 Oct 2009 20:55:06 -0000

> So these are the motivations behind our desire at least to provide the
> chaddr in the DHCP packet as a way to identify and classify clients.
> As I said in my other email, we have a working prototype that does
> exactly this for ISC dhcrelay.
My only objection to you proposing this is that it's clear to me from  
some of your early statements in this message that you actually intend  
to use the MAC address from the relay agent option as an identifier in  
place of DUID, and not as a hint for your back office system to use in  
connecting DUID-based identifiers to MAC-based identifiers.   This is  
unnecessary--what you're proposing completely solves your problems  
without requiring any change to RFC3315 or RFC4361.

So if you were to propose a protocol extension that included the MAC  
address in the relay agent options, and you were to describe how it  
could be used as a hint to relate DUID-based identifiers to MAC-based  
identifiers, I would be in favor of that.   But to the extent that  
your proposal essentially substitutes this relay-provided identifier  
for DUID-LLT, this would eliminate an identifier that is the same  
across all interfaces for the same device, and I would not support that.

One bellwether of this would be whether or not you expected a PXE boot  
loader that sends a different identifier than the OS client to get the  
same IP address that the OS client gets, because the relay-supplied  
MAC address is the same.   If you expect this, your spec breaks