Subject: [dhcwg] High Availability DHCPv6

From: "Brzozowski, John" <[email-masked]>
Date: Mon, 26 Feb 2007 07:44:44 -0500

Folks,

I have been doing some research and investigation on HA solutions for
DHCPv6, it seems that this is a topic that we will need to address as
adoption and use of DHCPv6 increases.  I assume that others in the WG
have too given this some thought.  I was hoping that perhaps we could
exchange some email on the dhcwg list to determine where we stand as a
group on this topic.

At this point I have been considering putting together an I-D (probably
informational) to outline what I have done thus far.  In advance of
doing this I wanted to reach out to you all.  Also, if there is
sufficient interest is this topic on the list I was thinking about
requesting a slot at the IETF68 dhcwg meeting so we can discuss in
person.

Comments, questions, and suggestions are most welcome.

Thanks,

John
========================================= 
John Jason Brzozowski (CISSP, RHCT)
Comcast Corporation
e) mailto:[email-masked]
m) 609-377-6594
p) 856-324-2671
dc) 168*45683*22
=========================================

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 27 Feb 2007 14:09:19 -0800

> requesting a slot at the IETF68 dhcwg meeting so we can discuss in

You could say the problem DHCPv4 solves is resource starvation.
A server presides over a limited resource, of which 80-90% is
consumed...so if you lost 50% of that resource, you're doomed.

Hence, the failover draft.

In IPv6 we've tipped that scale pretty far off into the ludicrous
range in the opposite direction (you could imagine dividing a /64
into 281 trillion server buckets to serve 256 clients!).

So the old model of having N DHCP servers, each presiding
over 1/Nth of the available resource, is realistically possible
in DHCPv6.

So there's already at least one mechanism that fits neatly
inside existing protocol work.

There is potential for other mechanisms, but is there a good
reason for one?  Is limiting address hopping part of the
requirements, if so why?

I think there is at least a good reason for defining a means
where a group of servers can determine one server out of a group
to respond (imagine if all 281 trillion answered in the ludicrous
example...the point at which additional replies become waste is
probably much smaller).

-- 
ISC Training!  http://www.isc.org/training/  [email-masked]
Washington DC area, April 16-20 2007.  DNS & BIND, DDNS & DHCP.
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 28 Feb 2007 09:25:01 -0500

David, et al:

Address assignment / resource starvation are only a small part of what
the DHCPv4 failover protocol addresses (sorry, no pun intended). 

And, while DHCPv6 stateful address assignment is not likely to be an
issue in terms of resource starvation, there are other allocations that
DHCPv6 is being asked to do that will likely be a fairly constrained
resource (i.e., Prefix Delegation).

While the <n> (where n is > 2) server model is a nice one, it causes the
same complexity issues as it did in DHCPv4 if you go beyond looking at
just the stateful address assignment issue.

>example...the point at which additional replies become waste is

If that's all you want to solve, consider RFC 3074's hashing on the
DHCPv6 Client Identifier option and you're pretty much there. But, I
think if you consider this more carefully with DNS updates, complex
networks with relays (especially when used as access concentrators),
etc., you'll quickly find that this is a rather limited solution.

- Bernie 

-----Original Message-----
From: David W. Hankins [mailto:[email-masked]] 
Sent: Tuesday, February 27, 2007 5:09 PM
To: [email-masked]
Subject: Re: [dhcwg] High Availability DHCPv6

On Mon, Feb 26, 2007 at 07:44:44AM -0500, Brzozowski, John wrote:
> At this point I have been considering putting together an I-D
(probablycisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1SEPDG0013403; 
	Wed, 28 Feb 2007 09:25:13 -0500
Content-class: urn:content-classes:message
Subject: RE: [dhcwg] High Availability DHCPv6
Date: Wed, 28 Feb 2007 09:25:01 -0500
From: "Bernie Volz \(volz\)" <[email-masked]>
To: "David W. Hankins" <[email-masked]>, <[email-masked]>
Cc: 

David, et al:

Address assignment / resource starvation are only a small part of what
the DHCPv4 failover protocol addresses (sorry, no pun intended). 

And, while DHCPv6 stateful address assignment is not likely to be an
issue in terms of resource starvation, there are other allocations that
DHCPv6 is being asked to do that will likely be a fairly constrained
resource (i.e., Prefix Delegation).

While the <n> (where n is > 2) server model is a nice one, it causes the
same complexity issues as it did in DHCPv4 if you go beyond looking at
just the stateful address assignment issue.

>example...the point at which additional replies become waste is

If that's all you want to solve, consider RFC 3074's hashing on the
DHCPv6 Client Identifier option and you're pretty much there. But, I
think if you consider this more carefully with DNS updates, complex
networks with relays (especially when used as access concentrators),
etc., you'll quickly find that this is a rather limited solution.

- Bernie

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 28 Feb 2007 11:16:43 -0800

My main concern (which I see now I edited out), is that we're
all very easily excited (myself included) at the prospect
of creating a new architecture of high availability.

But complexity is a price that must be justified by demand.

I want to know what the underpinnings of DHCPv6 'HA Demand'
are before we talk about the merits or failings of any one
design.

That's what I set out to say anyway.

I think IA_PD is an unknown, and at least one outcome is
that prefixes will be 'assigned' to customers rather than
dynamically allocated by the DHCP server.  No need for an
HA overlord there.

DDNS is quite possible with multiple servers, not sure what
you're hinting at.  RFC4073's example gives it away for
free.

"stateful relays" are a non-starter already.  We need to
define the way these things will work to start with...leasequery
without bulk updates clearly doesn't cut it...so we don't know
if that method will work well or poorly with existing protocol's
fault tolerance.  In this case, let's hatch the egg before we
fry the chicken?