Re: [dhcwg] Load Balancing for DHCPv6

Ted Lemon <Ted.Lemon@nominum.com> Wed, 29 August 2012 15:19 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0E521F86DC for <dhcwg@ietfa.amsl.com>; Wed, 29 Aug 2012 08:19:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.56
X-Spam-Level:
X-Spam-Status: No, score=-106.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVQXC024gSvo for <dhcwg@ietfa.amsl.com>; Wed, 29 Aug 2012 08:19:48 -0700 (PDT)
Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id C33F521F86DA for <dhcwg@ietf.org>; Wed, 29 Aug 2012 08:19:47 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUD4zE9mkhAhHUJHty0SCg/sHdthYWUKE@postini.com; Wed, 29 Aug 2012 08:19:47 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9BE08128005 for <dhcwg@ietf.org>; Wed, 29 Aug 2012 08:19:46 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 93481190060; Wed, 29 Aug 2012 08:19:46 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Wed, 29 Aug 2012 08:19:46 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Andre Kostur <akostur@incognito.com>
Thread-Topic: [dhcwg] Load Balancing for DHCPv6
Thread-Index: AQHNhTu7gFlX/ZntC0OFRh8xVQ/AAZdwtBEAgACi1QCAAAcoAA==
Date: Wed, 29 Aug 2012 15:19:45 +0000
Message-ID: <DF93BDD1-BBB9-4607-995C-C6244C56A5A5@nominum.com>
References: <CAL10_Bqa4ftiVhyyf0ezwKR7mzAEOLNi_K3EJFPFUzPnz7QGPw@mail.gmail.com> <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <CAL10_Br=OcWZuar1fDOopevTy_W-3g9TsYqo61rOWm4tKkuYgg@mail.gmail.com>
In-Reply-To: <CAL10_Br=OcWZuar1fDOopevTy_W-3g9TsYqo61rOWm4tKkuYgg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.1.10]
Content-Type: multipart/alternative; boundary="_000_DF93BDD1BBB94607995CC6244C56A5A5nominumcom_"
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com>
Subject: Re: [dhcwg] Load Balancing for DHCPv6
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 29 Aug 2012 15:19:48 -0000

On Aug 29, 2012, at 7:53 AM, Andre Kostur <akostur@incognito.com<mailto:akostur@incognito.com>> wrote:
Regarding DUIDs, what I do wonder about is DUID-EN.  How many devices out there actually use it (I have not encountered any as yet), and if they do, how variable are the first 10-12 bytes of the data that the vendor is choosing?   We could still skip the DUID type, but the enterprise ID will stil have some variability across the entire population (I suppose unless the DHCP servers are deployed in an entirely homogenous network).

We're likely only getting one bit out of this hash, so I don't think this is really an issue—a pair of plaintexts that match in the first 12 bytes and differ in the last two will still be likely to produce a different result, just as if the plaintext were only two bytes.