Subject: RE: [dhcwg] High Availability DHCPv6

From: "Brzozowski, John" <[email-masked]>
Date: Mon, 19 Mar 2007 05:35:38 -0400

Apologies for the delayed response, see comments below.
 
John
 
========================================= 
John Jason Brzozowski (CISSP, RHCT)
Comcast Corporation
e) mailto:[email-masked] <mailto:[email-masked]> 
m) 609-377-6594
p) 856-324-2671
dc) 168*45683*22
=========================================

________________________________

From: David W. Hankins [mailto:[email-masked]]
Sent: Tue 2/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 (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.

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!).

[jjmb] The scale indeed has been tipped, however, creating 281T server buckets as you illustrate is a bit extreme and would have some management and operational challenges.  Perhaps a smaller number of servers in a group collaboratively particpating in providing DHCPv6 services.  In this case it might not be necessary at all to divide the prefix into buckets.

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

[jjmb] Agreed.

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?

[jjmb]  Is there a good reason not to?  If now we potentially have a viable solution why not consider and build it?  Also one size may not fit all.  I can imagine other benefits to alternative approaches with varying applicability depending on the consumer.  I am not sure I follow what you are referring with regards to "address hopping", can you elaborate?

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).

[jjmb] Ok, so are you interested in having some discussion around this topic?

--
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: "Brzozowski, John" <[email-masked]>
Date: Mon, 19 Mar 2007 05:53:47 -0400

Bernie,
 
See below, also apologize for the delayed response.
 
John

From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Wed 2/28/2007 9:25 AM
To: David W. Hankins; [email-masked]
Subject: RE: [dhcwg] High Availability DHCPv6

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.

[jjmb] There is absolutely some additional challenges depending on the context and what we are asking DHCPv6 to do, to your point DHCP PD.  Another point perhaps in the other direction is statless DHCPv6 where we are not statefully assigning address, etc. 

>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.

[jjmb] Indeed RFC3074 would be applicable.  One of the benefits of openly discussing and or documenting this are related to some of the points you raise.  Personally, I think it would be good for our group if not the community overall to see some of these points.

- Bernie

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 19 Mar 2007 11:01:25 +0100

On Mon, Mar 19, 2007 at 05:35:38AM -0400, Brzozowski, John wrote:
> [jjmb] The scale indeed has been tipped, however, creating 281T server buckets as you illustrate is a bit extreme and would have some management and operational challenges.

"Ludicrous speed!" - _SpaceBalls_

> [jjmb]  Perhaps a smaller number of servers in a group collaboratively particpating in providing DHCPv6 services.  In this case it might not be necessary at all to divide the prefix into buckets.

It might not be necessary to divide the prefix - but doing so introduces
some complexity.  So is there a good reason not to?

I'm not a fan of dividing the prefix, that's just "what we have today".

> [jjmb]  Is there a good reason not to?

I think there is.

The IETF protocol work has famously been descirbed as "throwing
spaghetti at the wall to see what sticks."

This is a lot of fun for the people who throw the spaghetti.

But it's rather a chore from the wall's point of view (or the janitors).

If existing protocol gives rise to HA without addtiional work - we
should stop there, unless there is a compelling reason not to.

> [jjmb]  I am not sure I follow what you are referring with regards to "address hopping", can you elaborate?

Subdividing the address space means that the way the client moves from
his current server to a fault-tolerant peer is to change addresses
(hopefully during rebinding).

This might be graceful, or it might not, and it's hard to tell.  IPv6
tries hard to make these address transitions graceful.  The old lease
remains valid while new sessions build out on the new address.

Or at least that's the way it's supposed to work.

But since it tries so hard to make these transitions graceful, and
there is talk about to make them frequent occurances, it's really
not clear to me there's any reason to try and optimize outside of
this.

> [jjmb] Ok, so are you interested in having some discussion around this topic?

Absolutely.

---

From: "Brzozowski, John" <[email-masked]>
Date: Mon, 19 Mar 2007 09:01:22 -0400

Inline.
 
John

From: David W. Hankins [mailto:[email-masked]]
Sent: Wed 2/28/2007 2:16 PM
To: [email-masked]
Subject: Re: [dhcwg] High Availability DHCPv6

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.

[jjmb] I agree that doing this just to do is not wise.  Something also worth noting is that failover is not precluded, in fact, DHCPv6 failover must also be considered.  Points of view on benefits and failings may vary.  From my point of view some benefits could be reduced complexity for implementation and management as well as maxmizing server resources.  There may be other benefits as well as drawbacks.  In fact it is probably fair to say that there are pro's and con's to any solution.

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.

[jjmb] DHCP PD is unknown in what sense?  Manual allocation will not scale and I do see DHCPv6 being quite important for the dynamic allocation of prefixes.  Given this an HA solution will too have to account for PD.

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

[jjmb] I assume you meant to refer to rfc4703?

"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?

[jjmb] I agree that hatching this first makes sense and is largely the reason why I sent the original email.  Stateful relays, what are you referring to?  Also, are you saying that there needs to be some mechanism for retrieving lease data in bulk or are you saying it is not required?  If the former, there was a some good work that was done as part of the original DHCPv6 Leasequery ID which could be recycled.  Perhaps we should also revisit the topic of bulking leasequery, soon.

---

From: "Brzozowski, John" <[email-masked]>
Date: Mon, 19 Mar 2007 09:27:21 -0400

From: David W. Hankins [mailto:[email-masked]]
Sent: Mon 3/19/2007 6:01 AM
To: DHC WG
Subject: Re: [dhcwg] High Availability DHCPv6

[jjmb] :)

[jjmb] I agree that dividing the prefixes adds complexity, a complexity that could represent a rather significant problem.  Generally speaking I am not for this either.

I think there is.

[jjmb] This is a good point.  My personal goal was to keep this on the list until we as group determine whether or not we wish to pursue this further.  It would be great to hear from others on the list too.

[jjmb] There might be some other challenges in this type of scenario not just the gracefulness of transition from one IP to another.

Absolutely.

[jjmb] Should we organize brief meeting after dhc?

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 19 Mar 2007 15:00:32 +0100

On Mon, Mar 19, 2007 at 09:01:22AM -0400, Brzozowski, John wrote:
> [jjmb] DHCP PD is unknown in what sense?

We don't know how it's going to be "actually used" yet.

> [jjmb] Manual allocation will not scale and I do see DHCPv6 being quite important for the dynamic allocation of prefixes.  Given this an HA solution will too have to account for PD.

There's manual, and then there's "not by the dhcp server."

I hope that most networks would automate the process through which
"customers" are sold "products."

I think whatever device serves that function (or human if that's
really what you want...) could wind up being what allocates a prefix
to a customer.

So although having humans assign prefixes to customers probably
doesn't scale, I should also mention that the converse - allocating
prefixes to clients dynamically - possibly doesn't scale either,
or a client could exhaust a server's pool of prefixes very easily
(not true of addresses any more).

> [jjmb] I assume you meant to refer to rfc4703?

Yup, typo.

> [jjmb] I agree that hatching this first makes sense and is largely the reason why I sent the original email.  Stateful relays, what are you referring to?

Anything that needs to re-fetch client state in order to operate, such
as via a leasequery message or similar.

> Also, are you saying that there needs to be some mechanism for retrieving lease data in bulk or are you saying it is not required?

I think that the abdications the v6 leasequery authors made at the
behest of the WG were good - as described the mechanisms were just
too complex for DHCPv6/UDP.

I also think that in so doing, the solution no longer fits the
requirements.  A relay in such a network can no longer recover
the state which leasequery is designed to deliver.

This turns the existing leasequery message into an administrative
tool I think.

> [jjmb]  If the former, there was a some good work that was done as part of the original DHCPv6 Leasequery ID which could be recycled.  Perhaps we should also revisit the topic of bulking leasequery, soon.

Could be.  I think there are about 4 solutions on the table.

---

From: "Brzozowski, John" <[email-masked]>
Date: Mon, 19 Mar 2007 13:20:20 -0400

From: David W. Hankins [mailto:[email-masked]]
Sent: Mon 3/19/2007 10:00 AM
To: DHC WG
Subject: Re: [dhcwg] High Availability DHCPv6

[jjmb] Actually there are cases, or atleast one, where this will be used.

[jjmb] True

[jjmb] This is a must.

[jjmb] The provider should/must be able to govern this to ensure the PD prefix is not exhausted.

Yup, typo.

[jjmb] I guess I should know this -- which four solutions are you referring to?

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 19 Mar 2007 19:53:35 +0100

> [jjmb] I guess I should know this -- which four solutions are you referring to?

There haven't been any drafts yet...I'm referring to informal
suggestions in the hall at the last DHC WG meeting.  XML over
some TCP thing (I'm guessing HTTP GET) was Alain's suggestion
(and people seemed to like the idea for different but similar
purposes).  DNS, DHCPv6 over TCP, and you have to include the
original leasequery draft as one.

There's 4 to my count, anyway.

---

From: "Brzozowski, John" <[email-masked]>
Date: Mon, 19 Mar 2007 21:14:28 -0400

David,
 
I recall all but the DNS solution?
 
John

From: David W. Hankins [mailto:[email-masked]]
Sent: Mon 3/19/2007 2:53 PM
To: DHC WG
Subject: Re: [dhcwg] High Availability DHCPv6

---

From: Ralph Droms <[email-masked]>
Date: Mon, 19 Mar 2007 17:09:20 -0400

Inline... 

- Ralph

> We don't know how it's going to be "actually used" yet.

I'm pretty sure there are already production deployments of DHCPv6 PD from
SPs to subscribers.

>> [jjmb] Manual allocation will not scale and I do see DHCPv6 being quite
>> important for the dynamic allocation of prefixes.  Given this an HA solution
>> will too have to account for PD.
> 

The well-known methods of avoiding address exhaustion in DHCPv4 can be
applied to prefix delegation in DHCPv6.
 
>> [jjmb] I agree that hatching this first makes sense and is largely the reason
>> why I sent the original email.  Stateful relays, what are you referring to?
> 

I think it is important to differentiate between the DHCP relay agent
function and other networking functions that might be provided by a network
element.  Instead of "stateful relay", I would use "stateful network
element" that needs state related to DHCP functions.  The state in that
network element could be initialized and recovered as a side effect of DHCP
message exchanges or through some other network configuration management
mechanism.

>> Also, are you saying that there needs to be some mechanism for retrieving
>> lease data in bulk or are you saying it is not required?
> 

I'm getting confused.  Are we talking about the RAAN mechanism to deliver
state, the leasequery mechanism to recover state?

>> [jjmb]  If the former, there was a some good work that was done as part of
>> the original DHCPv6 Leasequery ID which could be recycled.  Perhaps we should
>> also revisit the topic of bulking leasequery, soon.
> 

Where are the docs describing these solutions?

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 20 Mar 2007 16:16:09 +0100

> I'm pretty sure there are already production deployments of DHCPv6 PD from

I don't doubt it.  The question is wether those production deploymens
allocate prefixes to a customer at point of sale, or dyanmically
allocate prefixes to customers at runtime.

I don't think any of us have seen sufficient field use of this to
begin to guess what "will be" the common practice (the kind of
common practice at a scale that warrants HA), so any statement we
make today is highly speculative either way.

> applied to prefix delegation in DHCPv6.

Are you talking about DHCPv4 authentication?  I'm not aware of any
actually deployed DHCPv4 technology that might be used to limit the
extent to which an attacker can deplete address resources, save the
attention of a human.

I can't think of any way to do it in DHCPv6, short of using
authentication and refusing to allocate resources to inauthentic
clients.

> state, the leasequery mechanism to recover state?

I have only mentioned or thought of leasequery in this context.  I'm
not sure why or how RAAN applies.

> Where are the docs describing these solutions?

They have not been written, to the best of my knowledge.

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 20 Mar 2007 20:09:32 -0400

To the last point, no documents have been written to date for any of the four alternatives.
 
I do not recall the DNS specific alternative, can you provide a high level refresher?
________________________________

From: David W. Hankins [mailto:[email-masked]]
Sent: Tue 3/20/2007 11:16 AM
To: DHC WG
Subject: Re: [dhcwg] High Availability DHCPv6