Re: [dhcwg] DHCPv6 Failover -- LAST CHANCE

tianxiang li <> Thu, 08 September 2016 02:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F02D12B0ED for <>; Wed, 7 Sep 2016 19:37:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q0UOIXrrImWd for <>; Wed, 7 Sep 2016 19:37:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3F6F312B0A7 for <>; Wed, 7 Sep 2016 19:37:48 -0700 (PDT)
Received: by with SMTP id s131so52811519oie.2 for <>; Wed, 07 Sep 2016 19:37:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HGS9s/YbbxiJ599DQ0kYhmfYOj/4OScwX+Ct0k1Gjxg=; b=qS5YrY3KyMPKdGHMskdyL8Ibe9Z77txKpNvHYcTVXBZ2Njle2wRAsPXLqEXd0j89CB 8YetFNwT1BAhJEgU7dP7acn/DySqz5nLPl7mzw2miRA07UTB7D/lNR8fbD2Z7y66f64v GoaihNCwjp+1vl9VdT1TYLkRYDphei0QUEuE41Z4WGgmkdGOPHrf7jFU+25oNahhGTSu 4esV8/PQszR8XJZtMLjld3eDyzIKkzP8LSjeag6Xrg1MEv4M/NSvlFIHP1Ql+jN+TZen yxTJ5e8iCxh5EQXgzU5yppg4m/6qCCtl1HlYGq4Xxuh2GJSXWasXiVtEgUo7US4llUHR KlQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HGS9s/YbbxiJ599DQ0kYhmfYOj/4OScwX+Ct0k1Gjxg=; b=C+kbi6DkRXJhFsKXVYkY4TejOuMP1JpLFaYOZpUUWBhdQ8b7vaaGGiMfOuwSa2kagb rsthfWtV6fMhG9w7BdSbO/gqlYu3oUR42F/PHR1ysyLVgqClLA2NkEZK0qiX0fiM4GRc baCFowJQfc4Cb0L4EqV5t19df9HLQC54JddJ8ijczBuoTV0KX60ctCLhBMXtl0hyXyS5 71Ur5GQaZgDFtSga93kAPbKGAWKx7S+jHOJnBF2Bh5fancE1SL1FbutrqIL9jY14Ijze 0pF5YiG7QrfqF5an+SmZqcdchjOE07xSCbEe/tLsMsoM/uSTt4vy9E+Kbjcs917m3MGU rTmw==
X-Gm-Message-State: AE9vXwNL1jJqyfMIMWkBTHqiDjElt7Js2yzafGKrJxkWZ5R/UNRiK3NVJCFSb9rsL2tfLE93PYsRLjpj08w9yg==
X-Received: by with SMTP id w129mr41430215oif.156.1473302267556; Wed, 07 Sep 2016 19:37:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 7 Sep 2016 19:37:06 -0700 (PDT)
In-Reply-To: <>
References: <>
From: tianxiang li <>
Date: Thu, 08 Sep 2016 10:37:06 +0800
Message-ID: <>
To: Kim Kinnear <>
Content-Type: multipart/alternative; boundary="001a11c183ce4dfa5a053bf5ea9e"
Archived-At: <>
Cc: dhcwg <>
Subject: Re: [dhcwg] DHCPv6 Failover -- LAST CHANCE
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Sep 2016 02:37:50 -0000


I think this a useful draft and I think it should forward. The DHCPv6
failover is an important mechanism with real network needs. It is quite a
long document and I read through part of it. I have a few comments below:

3. Glossary

“Delegable prefix: A prefix from which other prefixes may be delegated, as
described in [RFC3633].”

The term “delegable prefix” was never used in RFC3633, so maybe it should
be considered a new term defined in this particular draft?

4.2.1 Independent allocation

“In this allocation scheme, used for allocating individual IPv6 addresses,
available IPv6 addresses are permanently (until server configuration
changes) split between servers…”

If active-passive mode is used, it would mean that the addresses in the
secondary server would not be used unless the primary server fails. In that
case, wouldn’t permanently splitting the addresses between the primary and
secondary server a waste of addresses?

If the address pool in the primary server becomes scarce, wouldn’t a
rebalancing mechanism be useful?

4.2.2 Proportional Allocation

“The flow of a delegable prefix is as follows: initially the delegable
prefix is part of a larger delegable prefix, all of which are initially
owned by the primary server. A delegable prefix may be allocated to the
secondary server and then it is owned by the secondary server. Either
server can allocate and delegate prefixes out of the delegable prefixes
which they own…”

“In PARTNER-DOWN state the operational partner can delegate prefixes from
either pool (both its own, and its partner's after some time constraints
have elapsed)…”

How are the prefixes in the primary server passed on to the secondary
backup server in such a case? Should there be some text added here to
explain this?

These are my individual comments, please correct me if I misunderstood



2016-09-03 3:23 GMT+08:00 Kim Kinnear <>:

> We are well into the second and *last* WGLC for the DHCPv6 failover
> draft:
> <
> If there are not enough responses to the draft for this WGLC, we will
> drop it and not try again.
> We have some detailed technical reviews.  What we *really* need now
> are people to just read it and say:
>   "I think this draft should move forward".
> That's all you have to do.  Any review would be nice, but we really
> just need people to read it and send in email that says "move this
> forward".
> This is the last chance for DHCPv6 failover.
> Thanks -- Kim
> _______________________________________________
> dhcwg mailing list