Re: [dhcwg] Load Balancing for DHCPv6

Bud Millwood <> Fri, 21 September 2012 13:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDD4F21F845C for <>; Fri, 21 Sep 2012 06:32:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ISIQHDKBlIKV for <>; Fri, 21 Sep 2012 06:32:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C2BF521F87F3 for <>; Fri, 21 Sep 2012 06:32:46 -0700 (PDT)
Received: by iec9 with SMTP id 9so6192831iec.31 for <>; Fri, 21 Sep 2012 06:32:46 -0700 (PDT)
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; bh=nqjoHltghy5pvi19eSPqLolUpsPDvNUi9beExzXib6k=; b=GvElZJ+7LCWIR/5gz2X/UMNWpkws9bt579S/MShbah0tGKdV+aOSeqafjLcdrWsPrL yhhnlYs9on0oN0lqY23Q1yjzYlaGGseCLrtRPWabpPfLah6w9KCJvsS6YTiPD/eCfCvy TzklQDPNpf49pjLJcpuCGJDBZ0hpQQ6TrvU/nNP2hhBdjLBsSXS9Jm3jHLs3nT50Ugj0 U/+5HcKM28Qg/+V5+OW0nWzjLtKkyYMz9eX4KvSQ0bCpqc8QzN4egC2yajgV9Ig02SXV jQ9oTOtz4BX/jXdGpwjjuJd6uIkKec0quaiLFx3I007iIwmO3fNHwiLximzuqQ9+WATY G03A==
MIME-Version: 1.0
Received: by with SMTP id gs5mr1658453igc.32.1348234365897; Fri, 21 Sep 2012 06:32:45 -0700 (PDT)
Received: by with HTTP; Fri, 21 Sep 2012 06:32:45 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Fri, 21 Sep 2012 15:32:45 +0200
Message-ID: <>
From: Bud Millwood <>
To: Andre Kostur <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "" <>, "Bernie Volz (volz)" <>, 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 13:32:59 -0000


I think the only reasonable way to move clients back to server A is
what you suggest. You are essentially doing the same thing as the
failed server A did when it failed - going offline - but you're just
doing it administratively, and just for a subset of clients. It causes
a degraded performance mode on your network, but you have to balance
that against the desire to split the load after server A has come back

It's not a failover problem so much as it's a load balancing problem.
For example, suppose you wanted to change the load balancing split to
70/30 instead of 50/50 on a running network - you'd use the same


> However, it does complicate Request packets because failover doesn't
> usually exchange tentative bindings from a Solicit and so you really would
> only want the server that Solicited to respond to the Request (this could
> be done by looking to see if you had a tentative binding - but if neither
> server does, the client has to suffer a Request timeout to get back to the
> Solicit phase).

Is this a problem because under normal circumstances, the server could
allocate a lease on the spot in response to the Request (i.e., without
having seen a Solicit)? It seems like a reasonable tradeoff - to
disallow a failover partner from short-circuiting the full lease

- Bud

On Tue, Sep 18, 2012 at 6:42 PM, Andre Kostur <> wrote:
> On Tue, Sep 18, 2012 at 9:24 AM, Bernie Volz (volz) <> wrote:
>> First, I think this would be a rather bad change to DHCPv6 operation.
>> Client may be checking the server-identifier option they get back and so
>> you would have to lie about that in the response which just seems like a
>> very bad thing to do. (I don't believe RFC 3315 actually ever states the
>> clients should be checking the server-identifier, but I could be wrong --
>> section 15 does say they check for the presence of the option, but do not
>> check the contents). One could also think of situations where a relay
>> agent might forward the packet to explicit destinations based on the
>> server identifier (though again, I doubt anyone does this) -- much like
>> switches limit traffic based on mac-addresses.
> Note that I didn't suggest that server A preemptively answer the Renew
> coming in from the client (or impersonate server B).  Under my
> suggestion, the Renew would arrive at both servers A and B.  B would
> ignore it due to load balancing, and A would also ignore it due to the
> server ID.  The client continues to retry the Renews for the
> appropriate time, until it is time to Rebind.  At that point server B
> is still ignoring the client, but now A can answer the client as the
> Rebind isn't carrying a Server ID.  (And if we are talking about a
> Failover pair, then server A would already have a lease record for
> this client, and can extend that same lease.)
> For the relay piece, it would still need to forward the Rebind to both servers.
> [snip]
>> Anyway, I think this needs to be thought through much more carefully as to
>> the potential consequences and I think the best is to keep it simple -
>> once a client has 'bound' to a server, it stays with that server until it
>> issues a request message which does not contain a server-identifier option.
> My scenario doesn't result in a client switching servers except under
> already defined RFC 3315 behaviour when the client has transitioned
> into Rebind.
> One piece that may have funny consequences is if the pair of DHCP
> servers aren't in some sort of cooperation mode, and this scenario
> would result in the client possibly changing IP addresses.  Client has
> to rebind, and server A does the DHCPv6 equivalent of a NAK and forces
> the client to come back to get a new IP.    Perhaps a server MAY skip
> the load balancing if the packet contains a Server ID (or even
> limiting it to the server's Server ID)?
> --
> Andre Kostur
> _______________________________________________
> dhcwg mailing list