Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-load-balancing-01 - Respond by March 31, 2014

Tomek Mrugalski <> Fri, 11 April 2014 17:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5B84A1A0286 for <>; Fri, 11 Apr 2014 10:37:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1OiLdyWVO8h8 for <>; Fri, 11 Apr 2014 10:37:26 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4013:c00::231]) by (Postfix) with ESMTP id DBD351A070D for <>; Fri, 11 Apr 2014 10:37:25 -0700 (PDT)
Received: by with SMTP id c41so4401358eek.36 for <>; Fri, 11 Apr 2014 10:37:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=uI1ipDDCymfe8i8+5g+3QPOZpZgSp99OGHS62RP7P4c=; b=VPo1tuHHELiRoHDsJDHtN2HEUZH9DevbIygzuvWeeLBfiJVfEBYMmpMI769RB9sED5 Z6Eb9aJvQx8UAlc2oq7zjk83J/bImthyJFhw00KXJXcf5GwDLfO/FaXOZQ0MiWBo2oil 7xqB+FuIvXGNqO3fBnRnMMFFNiZnzizV/WOOxiw4WNRwOwmRwl1+9vfclYaZOFHPWC9N HGiQ6JsBf+wRK0Mw5spSUwio8EwS4g9mi8C9wDlYptfcGyibeYTf17PMhXGOJjZQNGeO cwHXJ/YcSyS5ZaCKtolzIRBaIeE7dOkc2HjtUmLtOVmwREIK0verv0SxvNWlAOmxJiOb xU7Q==
X-Received: by with SMTP id n13mr30700043eew.17.1397237844004; Fri, 11 Apr 2014 10:37:24 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id q49sm19120134eem.34.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Apr 2014 10:37:22 -0700 (PDT)
Message-ID: <>
Date: Fri, 11 Apr 2014 19:37:19 +0200
From: Tomek Mrugalski <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Bernie Volz (volz)" <>, "" <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
X-TagToolbar-Keys: D20140411193719528
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-load-balancing-01 - Respond by March 31, 2014
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Apr 2014 17:37:28 -0000

On 13.03.2014 03:36, Bernie Volz (volz) wrote:
> This WGLC is for draft-ietf-dhc-dhcpv6-load-balancing-01. Please send
> your comments by March 31, 2014. If you do not feel this document should
> advance, please state your reasons why.
Apologies for late response, I was on vacation.

I did carefully review draft-ietf-dhcpv6-load-balancing-01 and have some
comments. The text mostly addresses my previous concerns, but there are
still some minor corrections to be made. I support this document moving
forward and all issues mentioned below can be fixed in updated revision
after WGLC.

Even though the list may seem a bit long, these are really easy to fix

1. I think you can drop the "DHC" from the title. It's name of the
working group, not the algorithm. Or even make the title shorter and
also drop "Algorithm". "Load Balancing for DHCPv6" is short and gets the
message across.

2. The new text in Introduction section mentions servers load and refers
to section 5.3 of RFC6853. That section mentions client requirements.
You probably meant some other section?

3. In section 3 the new text says: "LEASEQUERY [RFC5007] messages with a
query based on IP SHOULD NOT have load balancing applied to them." I
would make it MUST NOT. Also "LEASEQUERY and its extensions...". That's
sort of obvious that bulk and active leasequery are out of scope for
load balancing as they are TCP based, but it's better to be explicit here.

4. "LEASEQUERY messages with a query based on Client ID SHOULD have load
balancing applied to them". This one is interesting. I would assume that
leasequery messages are sent to specific server directly, so they are
outside of scope for load balancing. Furthermore, I think it is legal to
send QUERY_BY_CLIENTID queries over TCP connection. Obviously, load
balacing is out of scope for any TCP connections.

I don't have any strong opinion here, but I think leasequery should be
not load balanced at all, regardless of the query type. I talked about
this with Bernie and he seems to agree with that. If you still want to
keep that text, I think it should say "LEASEQUERY message with a
QUERY_BY_CLIENTID that are sent over UDP SHOULD have load balancing
applied to them."

5. Also in section 3: "Load balancing only applies to incoming UDP
DHCPv6 messages that servers would normally process: SOLICIT, REQUEST,
RECONFIGURE-REQUEST [RFC6977]." That's an unfortunate choice of words.
The text may be interpreted as if these were the only messages that
server processes, which is not true. Server will process any messages
that it received, including LEASEQUERY, RELAY-FORW and others. Perhaps
adding "client-originated UDP DHCPv6 messages" would be better? Or
saying "Load balancing only applies to the following incoming UDP DHCPv6

6. Still in section 3: "DHCPV4-QUERY [I-D.ietf-dhc-dhcpv4-over-dhcpv6]
messages SHOULD NOT be load balanced, but should be subject to DHCPv4
load balncing, if the server supports it.". Did you want the second
"should" to be capitalized?

That one is interesting. Right now the DHCPv6 relay does not need to do
any special about DHCPv4-over-DHCPv6 messages, just forward them towards
the server (it may do fancy things, but it doesn't have to). With this
statement, suddenly it becomes much more complex, as the DHCPv6 relay
should become DHCPv4 aware, DHCPv4 LB aware and have separate
configuration for DHCPv4 LB. Nowadays, realistically speaking relays
which do LB for DHCPv6 will also do LB for DHCPv4. But this may not be
the case in a decade or so.

7. As I pointed out earlier
(, it
would be good to mention in the security considerations that if the hash
buckets are misconfigured, some clients would be ingored. It is not a
security threat per se, just a new failure mode that is introduced by
this draft. Personally, I think it is worth mentioning, but I won't
insist on it if you think otherwise.

8. There is an informative reference to I-D.ietf-dhc-dhcpv4-over-dhcpv6,
but the normative text uses it. I'm afraid this is a normative, not an
informative reference. It's ok to have normative references to other
drafts. It introduces a dependency, but dhcpv4-over-dhcpv6 is sent to
IESG already, it shouldn't delay this work.