Re: [dhcwg] Load Balancing for DHCPv6

Andre Kostur <> Fri, 21 September 2012 14:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A239621F8319 for <>; Fri, 21 Sep 2012 07:52:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.977
X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KY4ALcKJgbYC for <>; Fri, 21 Sep 2012 07:52:47 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id E6E2221F8797 for <>; Fri, 21 Sep 2012 07:52:46 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKUFx/; Fri, 21 Sep 2012 07:52:46 PDT
Received: by iec9 with SMTP id 9so6442627iec.31 for <>; Fri, 21 Sep 2012 07:52:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=vfVUkXfo+sT1O5ADqM/sKa/qAfquTYbDV2+RJJCTLqQ=; b=MggC0Dn2I6LPGU4kNt8klw7iUQtziLaxE5pi0O1WhaVqpX9NyBp3Yj6GvBL9PRmjDp B5BuMQ55mFj86OptX0BUDT7226LOy4cpZ9sSMi1LJq52Iz9NSl9DNhKo5JTuI22qln91 0msuK4BSTj7m578JO0kq559T5J+H2Z03EERXyZDf7d7Nh0uO4Spd7knMhe5fzrB8eF63 cNLJ+2JG6lsc2KpPDn08RXIL3Zw6Pzq253b3nHI6XYzJFRTxR9ydb03+/LCy+rFC/Bsn dVww2zO90SwJJCGeNyk4WT78Rz8s9H7kGbRJEO1gU2kiEbR4TTBf6+Y1EKacpP093AGR 9EJw==
MIME-Version: 1.0
Received: by with SMTP id ew4mr1944546igc.5.1348239165462; Fri, 21 Sep 2012 07:52:45 -0700 (PDT)
Received: by with HTTP; Fri, 21 Sep 2012 07:52:45 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Fri, 21 Sep 2012 07:52:45 -0700
Message-ID: <>
From: Andre Kostur <>
To: "Bernie Volz (volz)" <>
Content-Type: text/plain; charset="ISO-8859-1"
X-Gm-Message-State: ALoCoQkfEDS/uManvfJA/IhV/TDXGDNpdm98YSc1VRLqI5The8xuWyBHHqzxEIlRz667iuTKlpeQ
Cc: "" <>, Ted Lemon <>
Subject: Re: [dhcwg] Load Balancing for DHCPv6
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Sep 2012 14:52:59 -0000

One note about the failover part of this dicussion.  I note that the
v4 load balancing was split away from the failover discussion (and
this draft is trying to follow v4 load balancing), and as such the
load balancing needs to be able to work in the absence of failover.
Perhaps the two servers are sharing IP space, say a 50/50 split of a

On Fri, Sep 21, 2012 at 7:36 AM, Bernie Volz (volz) <> wrote:
> However, Andre's proposal would be that if the server-duid matches but
> load balancing says that this is not the server that should be responding,
> to drop the request. This would thus force the client to return to Solicit
> (when the Requesting times out) or to advance to Rebind (when renewing

The Solicit to Request should be a pretty rare problem.  This would
have to occur if the server that had answered the Solicit failed
before the device managed to get its Request in.  And in that case, I
don't think making it retry the Solicit is unreasonable.

> between T1 and T2). This would work to move the client to the "correct"
> server but it does increase the traffic and load for those packets that are
> dropped.

It may increase the total traffic load, but functions to migrate the
load away from one server to split it again to two.  (Or as Bud had
mentioned, make a new division instead of 50/50)

> This would generally only impact Request and Renew packets. I would think
> that the server should always process Release and Decline since those are
> limited in their retransmissions (and the client fallback is to stop
> sending).
> So, I think when both failover partners are responsive the load balancing
> processing would be:
> - If server-duid not represent in request (Solicit, Rebind, Confirm,
> Information-Request), use load balancing to determine if server responds.


> - If server-duid present and doesn't match this server, drop packet
> (standard RFC 3315).


> - (server-duid present and matches server), if Request or Renew still use
> load balancing to determine if server responds.

Yep, contemplating the other packet types.

> - Otherwise respond to client.
> - Bernie

One thing that I think has been overlooked, what about the Relay that
may be doing Load Balancing?  It doesn't have the server's DUID to
make this comparison at all, and thus cannot do this determination.

Andre Kostur