Re: [dhcwg] Load Balancing for DHCPv6

Tomek Mrugalski <tomasz.mrugalski@gmail.com> Fri, 07 September 2012 09:49 UTC

Return-Path: <tomasz.mrugalski@gmail.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 A208F21F876F for <dhcwg@ietfa.amsl.com>; Fri, 7 Sep 2012 02:49:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 YHYmUJ1BkYIA for <dhcwg@ietfa.amsl.com>; Fri, 7 Sep 2012 02:49:17 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1870E21F8763 for <dhcwg@ietf.org>; Fri, 7 Sep 2012 02:49:15 -0700 (PDT)
Received: by eekb45 with SMTP id b45so1145053eek.31 for <dhcwg@ietf.org>; Fri, 07 Sep 2012 02:49:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=aEKim4rqIRNkv7iPIYj4LaSP6RA8nuhXGLGko+xvz/g=; b=s9QHW2cJSK8N23vyuHUKfu7OEo14kfpFLGwcJ5z+8V03n92QB23IZPg6XyRxmQvwZj mYFCTQ1psXqLs4bIaPzgbn83MuT6D90IROEPCn9LJTwWvG1bw1TBI+Q3OPi8/LkTbHxi mmXW9eofPSw5N/9CZPn8wvifKISJKOphIAZJ3r+VwlCo/ZWVs6Exon17jFqoHAGetKL8 J1fEyvx9lPhXNuId6sQt7Uq1vD2L0i1cvopJEmuCmVV2NddP1okXtPxlLy9M8Rq58HXL 42QFhVv8L7YLIlvml3BHmpqW7AWtZOC391P/w8Av94IYBaM8+nLniOdhA+hcGmwmXs/r RlBQ==
Received: by 10.14.223.9 with SMTP id u9mr6986915eep.10.1347011355309; Fri, 07 Sep 2012 02:49:15 -0700 (PDT)
Received: from ?IPv6:2001:470:6061:1:e086:e8e7:836c:20ad? ([2001:470:6061:1:e086:e8e7:836c:20ad]) by mx.google.com with ESMTPS id e42sm11198791eem.8.2012.09.07.02.49.13 (version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 02:49:14 -0700 (PDT)
Message-ID: <5049C317.7090603@gmail.com>
Date: Fri, 07 Sep 2012 11:49:11 +0200
From: Tomek Mrugalski <tomasz.mrugalski@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: dhcwg@ietf.org
References: <CAL10_Bqa4ftiVhyyf0ezwKR7mzAEOLNi_K3EJFPFUzPnz7QGPw@mail.gmail.com> <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <CAL10_Br=OcWZuar1fDOopevTy_W-3g9TsYqo61rOWm4tKkuYgg@mail.gmail.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> <CAL10_BpXdx03WfV1PeMKg1zYc1dAFKe1CDNdrcNf45+_EVCBPg@mail.gmail.com> <CDDB9016-BE11-489A-9361-0172D96A464C@nominum.com> <CAOpJ=k2CJS=FuUvFwOq=s2m871_qfo=xROsW=fx0E48w2wxAqQ@mail.gmail.com> <CAL10_BoLsdppYKNSfHheYrZg+SfaggoynQf2X11HEdy=ELFUiQ@mail.gmail.com>
In-Reply-To: <CAL10_BoLsdppYKNSfHheYrZg+SfaggoynQf2X11HEdy=ELFUiQ@mail.gmail.com>
X-TagToolbar-Keys: D20120907114911385
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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: Fri, 07 Sep 2012 09:49:17 -0000

On 06.09.2012 23:43, Andre Kostur wrote:
> bytes (only 2 beyond the 16).  The only one that is more of a question
> mark is DUID-EN as the vendor-specific identifier could be of
> arbitrary length.  The one case that we've heard of so far puts the
Sort of arbitrary, until you hit the limit of 128 octets, imposed by
3315 section 9.1. I'm ok with lifting the 16 bytes limit (or rather
extending it to 128 bytes).

There are some devices out there that are using DUIDs with duid type 14.
I have no idea what those devices are, I just saw traffic captures from
a production network. It is odd, but any server that follows 3315,
section 9 ("servers MUST treat DUIDs as opaque values") will handle them
ok. Anyway, my recommendation is to include the whole DUID as is in the
hash and don't to any clever things with duid types.

Regarding hashing algorithm, I never heard anyone complaining about it.
So don't fix it if it isn't broken. It can handle data chunks up to 128
bytes, right?

Tomek