Re: [dhcwg] Load Balancing for DHCPv6

"Bernie Volz (volz)" <volz@cisco.com> Fri, 07 September 2012 11:16 UTC

Return-Path: <volz@cisco.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 D430521F87D7 for <dhcwg@ietfa.amsl.com>; Fri, 7 Sep 2012 04:16:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 ok1TgrIo1d4c for <dhcwg@ietfa.amsl.com>; Fri, 7 Sep 2012 04:16:27 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 50AF921F87B9 for <dhcwg@ietf.org>; Fri, 7 Sep 2012 04:16:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1515; q=dns/txt; s=iport; t=1347016587; x=1348226187; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Emf+DQSG5PxFO8nUyvF66IdGQO/74WYxJNb13Fqc6no=; b=gv1Ii9wIuvBe9cY3ihA9L89/6CiSrdE2ZwbV2jmAQQ+JPPdFApK+Az+w z42nNrNyhGuLUhdbNc3XTLmJjlxyvUKB1H6X2HDRgWoqw5C2vQWJcFSv+ lXmCm+V4KEEfLCqp1+5/85ztlaspsdGtcpJ3nsjubs+aJKOdtvDWzpI08 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EANXWSVCtJXHA/2dsb2JhbABFuzmBB4IgAQEBAwEBAQEPASc0CwULAgEIDgoeECEGCyUCBA4FIodcAwkGC5sglmUNiU8Eii9jFYU/YAOUCIFVixSDIYFngmSBWw
X-IronPort-AV: E=Sophos;i="4.80,385,1344211200"; d="scan'208";a="119268644"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 07 Sep 2012 11:16:26 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q87BGQpc001065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Sep 2012 11:16:26 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Fri, 7 Sep 2012 06:16:25 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Tomek Mrugalski <tomasz.mrugalski@gmail.com>
Thread-Topic: [dhcwg] Load Balancing for DHCPv6
Thread-Index: AQHNjN4IqDjW3gEpckeBYuf8K4cCpZd+urP1
Date: Fri, 07 Sep 2012 11:16:25 +0000
Message-ID: <94FA926F-2432-4AE7-BC20-AE7458AB40D9@cisco.com>
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>, <5049C317.7090603@gmail.com>
In-Reply-To: <5049C317.7090603@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19168.005
x-tm-as-result: No--50.472700-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
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 11:16:27 -0000

Yes it can handle any length of data - the 16 limit came from max of chaddr. There is no harm in using whole duid, skipping type just reduces bytes used and as that field varies little it adds little.

Sent from my iPad

On Sep 7, 2012, at 5:49 AM, "Tomek Mrugalski" <tomasz.mrugalski@gmail.com> wrote:

> 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
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg