Subject: [dhcwg] draft DHC meeting minutes

From: Sheng Jiang <[email-masked]>
Date: Wed, 13 Aug 2014 05:51:18 +0000

Hi, DHC WG,

The below is the draft DHC WG meeting minutes. If there is any corrections, please send to DHC WG secretary Sheng Jiang ([email-masked]).

Best regards,

Sheng

DHC meeting start at 9am, Saloon room B, 23 July 2014.

Andrew volunteered as jabber scribe. Thanks!

Sheng has been assigned as DHC secretary

WG documents status review

Sheng: we haven't found solid use case of Stateless Reconfiguration

Sheng: more reviews on address registration draft would be helpful. Authors solved all comments received. WG should go second WGLC later.

Bernie: WG is going through a minor recharter

Ian: introduce Yang Model for DHCPv6 client

*******Presentations Split Line*******
Tomek: report on 3315bis work

Ted: should adopt first, and then require consensus process work

Bernie: the authors would like to get consensus internally in the group and address all known issues before adopt, then people can review a complete version during adoption call

Tomek talking about the server may ignore the hint from client

Ole: prefix length as a hint should also be able to be ignored

Tomek: it is not intended that server must accept what the client requested, might need some rewording.

Ted: should split the cases

Bernie: client should be survive if it does not get what the hint required, would make this clear in the document

Suresh: it may be out of scope. The client implementation could be: give me what I want or nothing.
Bernie: in general clients should accommodate what are form operators

Ted: provide another scenario (maybe a separated draft)

Lorenzo: how this hint relevant to SLAAC should also be considered

Michael Abrahamsson: a use case for client-initiated renumbering, e.g. customers don't want the current assigned prefix, and to get a new one through some mechanism

Bernie: it is not clear how the hint should be handled generally

Ole: is it ok to ask container option without suboptions?

Tomek: yes

Tomek talking about the Client Rate Limiting issue

Sheng: server should also be able to limit the request rate from the same client

Tomek talking about filling link-address

Ted: more detail should be given why and how to do it, may be a separated document

Bernie: just a recommendation that basically you should use a Global or Unique Local address for relay

Fred: give an example

Tomek talking about "confirm no longer mandatory"

Bernie, Ted: it should be a "SHOULD"

*******Presentations Split Line*******
Bernie talking about stateful issues

Sheng: update to 3315 and 3363 should also be in 3315bis

Bernie: has not been included in 3315bis, until WGLC

Tim Winters: there are clients that actually doesn't accept top-level status, but they do handle status in IA_NAs.

Reviewers Fred Templin, Leaf Yeh, Francis Dupont, Jason Weil, Ian Farrer, Andrew Yourtchenko, Qi Sun, Cong Liu

*******Presentations Split Line*******
Dacheng talking about Secure DHCPv6 with public key

Daniel: add trust anchor is not that difficult, leap of Faith is enough to make sure client connect to the same server

Lorenzo: not sure what the threat model is, if there is strong L2 security, might not need this

Maraus: prefer option 4 (drop certificate from this draft totally)

Daniel: it is useful for client to authorize server

Ted: server authorize client is also useful, though not very clear

Lorenzo: l2 security may be enough and better

Ted: client authorize server is more useful. Secure DHCPv6 regardless server or client is good.

Francis: URL for certificate may be help

Lorenzo: should get data to continue this work

Bernie: at least one use case that the client authenticates the server

Suresh: how to prove a DHCP server out of leap of faith

Ted: the point is to talk to the same server that the client has talked before

Maraus: support

Suresh: Leap of faith make sense, others don't

Bernie: the authors could summarize the discussion and come back to mail list for WG consensus

*******Presentations Split Line*******
Tomek presenting Customizing DHCP Configuration On the basis of Network Topology

Suresh: ask a question regarding to normative reference, DHCP base reference was moved to informative, it should remain normative

The feeling in the room is that the draft is ready for WGLC

*******Presentations Split Line*******
Qi Sun talking about Dynamic Allocation of Shared IPv4 Addresses

Ted: is this required for lightweight 4over6?
Qi: no

Ted: this seems softwire WG requirement

Suresh: as softwire chair, read this draft, but not have made up mind yet.

Ian: explain the history of the document

Bernie: will do WGLC on mail list

*******Presentations Split Line*******
Kim talking about DHCPv6 failover update

No comments

*******Presentations Split Line*******
Tomek talking about DHCP privacy considerations

Tomek: is the WG interested in working on this?

Bernie: first step is to write a document

Ted: useful work

Daniel: happy to help from outside of DHC WG

Lorenzo: the work is too difficult; recommend not working on this

Daniel: if so, we should document the difficult

Francis: analysis first, don't jump to any solution yet

Suresh: there are spaces within DHCP to improve (The document Daniel mentioned is RFC 6973 - Privacy Considerations for Internet Protocols)

Ted: IESG is interested in privacy, even give some hint whether using DHCP or not

Lorenzo: support analysis work first, disagree analysis and solutions doing at the same time

Mikeal Abramhamsson: SEND is hardly ever alive in practice, so please develop something deployable

Tomek: who is interested to work on it?

Suresh, Sheng, Tomek, Francis, Andrew raise hands

*******Presentations Split Line*******
Li Xue talking about DHCP for dynamic GRE tunnel

Bernie: question for AD, is DHC WG right place for this work?

Ted: where the requirements come from?

Li Xue: OPS open WG

Ted: need OPS AD to request this

Ian: 1. many terms in the draft makes the draft hard to understand.2. There is no standard track for GRE over IPv6.

Andrew: CAPWAP may be better option

*******Presentations Split Line*******
Suresh talking about support for multiple provisioning domains in DHCPv6

Suresh: it is an ongoing work in MIF WG

Ian: DHCPv6 relay agent supporting OPTION_PVD_ID would be useful

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Aug 2014 15:57:27 +0000

Hi, does anyone have a rough order-of-magnitude idea of how many clients
a single DHCPv6 server can handle? Assume clients normally send Request
once upon startup and send Renew/Rebind once in a while according to
timers and network conditions. They also send Release only when they
shut down, which could be one or a few times per day.

In such a system, how many clients can a server handle? O(10^3)?
O(10^4)? O(10^5)? More?

Any other tips on how to size a system like this?

Thanks - Fred
[email-masked]

---

From: Simon Hobson <[email-masked]>
Date: Fri, 15 Aug 2014 17:17:10 +0100

> In such a system, how many clients can a server handle? O(10^3)?

How long is a piece of string ?
Which server package you use will probably make a big difference. After that, hardware performance (particularly disk I/O) and system config rule.

It's come up over on the ISC DHCP users list a few times in relation to serving IPv4 addresses, but it shouldn't be much different for IPv6. Speaking only for the ISC server, there are reports of people running several hundred k of users off a server (or server pair). For that, I assume they will have chosen "beefy" hardware.
A key bottleneck for an RFC compliant server is disk I/O as leases must be synced to persistent storage before offer to the client - not all servers do this, gain a big performance advantage, but aren't RFC compliant and will lose lease information in an "uncontrolled shutdown" event. That means a very large number of small disk writes. Second to that comes logging - the ISC server defaults to logging every activity, and some setups default to synchronous logging. That can mean 6 disk writes for a single Discover-Offer-Request-Ack cycle (again speaking IPv4 terminology as I've not got into IPv6 DHCP yet) - 2 lease file writes, 4 log file writes. Setting logging (syslog config on unix-like systems) to asynchronous removes 4 of these writes from the equation.

So for high transaction rates, you need adequate processing power, ideally plenty of memory so all the tables can stay in RAM, and a disk I/O system that supports a high rate of small write transactions.

AFAIK there is no magic formula for sizing a DHCP server.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Aug 2014 16:25:15 +0000

Hi Simon,

Thanks for the great information - this is exactly the kind of stuff I
was hoping to learn more about. So, servers as a performance bottleneck
and single point of failure is probably something I'll want to account
for in my design. Any other ideas are also welcome.

Regards - Fred

> -----Original Message-----
> From: dhcwg [mailto:[email-masked]] On Behalf Of Simon Hobson
> Sent: Friday, August 15, 2014 9:17 AM
> To: [email-masked]
> Subject: Re: [dhcwg] DHCPv6 server scaling
> 
> Which server package you use will probably make a big difference. After that, hardware performance
> (particularly disk I/O) and system config rule.
> 
> It's come up over on the ISC DHCP users list a few times in relation to serving IPv4 addresses, but it
> shouldn't be much different for IPv6. Speaking only for the ISC server, there are reports of people
> running several hundred k of users off a server (or server pair). For that, I assume they will have
> chosen "beefy" hardware.
> A key bottleneck for an RFC compliant server is disk I/O as leases must be synced to persistent
> storage before offer to the client - not all servers do this, gain a big performance advantage, but
> aren't RFC compliant and will lose lease information in an "uncontrolled shutdown" event. That means a
> very large number of small disk writes. Second to that comes logging - the ISC server defaults to
> logging every activity, and some setups default to synchronous logging. That can mean 6 disk writes
> for a single Discover-Offer-Request-Ack cycle (again speaking IPv4 terminology as I've not got into
> IPv6 DHCP yet) - 2 lease file writes, 4 log file writes. Setting logging (syslog config on unix-like
> systems) to asynchronous removes 4 of these writes from the equation.
> 
> So for high transaction rates, you need adequate processing power, ideally plenty of memory so all the
> tables can stay in RAM, and a disk I/O system that supports a high rate of small write transactions.
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Andre Kostur <[email-masked]>
Date: Fri, 15 Aug 2014 09:33:14 -0700

That would be a discussion for the various DHCPv6 vendors.  That would
depends on way too many factors beyond the scope of the standards
committee.  What would affect Incognito's performance may be different
from Cisco, and ISC, and Nominum, and... etc.

-- 
Andre Kostur

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 Aug 2014 13:12:22 -0400

> In such a system, how many clients can a server handle? O(10^3)?

A good commercial server ought to be able to handle millions of clients at practical lease durations.   The ones I am familiar with do.

---

From: Simon Hobson <[email-masked]>
Date: Fri, 15 Aug 2014 19:23:09 +0100

Another factor I forgot is your lease time - the longer the lease time, the less frequently each client needs to renew.
But, that's not the whole story.

In a business environment, you may find that a large proportion of your devices get switched on during a fairly small time window every morning. Thus while the average renew rate may be low - the peak rate may be high. Similarly, you also need to consider abnormal events - such as a power outage over a large part of your estate. When the power comes back on, a large number of clients renew at once - especially if it's "always on" kit like consumer routers.

So again, it's not straightforward to work out what peak request rate you need to support !

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 Aug 2014 14:33:17 -0400

> But, that's not the whole story.

Has anybody written up an informational document that talks about these issues?   I confess I am not aware of one.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Aug 2014 18:40:46 +0000

Hi Simon and Ted,

Per your observations, scaling properties sound very reasonable modulo
power outages and the like. So, I was thinking it might be best to have
redundantly replicated servers. Each one could handle multitudes of
clients if necessary, but we would expect the client load to be fairly
evenly distributed among servers in the average case. That way, even
during synchronized start-ups like after a power failure client requests
should still be satisfied within a reasonable timescale. I expect to
have more to say about this soon.

Thanks - Fred

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 15 Aug 2014 19:54:13 +0000

This is a fairly complicated issue since servers also typically have a many features and depending on which ones are enabled/in use, performance can vary considerably (consider logging, failover, DNS updates, Leasequery (singleton, bulk, active), lease history, ...). Even the configuration complexity can have a (hopefully small) impact.

The Cisco Prime Network Registrar server can handle a lot of load, but as you turn on various features the performance will be impacted (that various of course by feature).

I think all servers are MOST impacted by disk performance - how fast they can commit the lease information to disk since they must commit to disk before responding to the client (although as Tomek recently pointed out to me, RFC 2131 has such a requirement whereas RFC 3315 apparently does not state this explicitly).

On the flip side, rarely is CPU performance the limiting factor (especially with any reasonable system today). DHCP (even DHCPv6 with longer addresses) is not CPU intensive.

So when you are buying equipment, you should spend the money on a very high performance disk I/O subsystem (high RPM disks or solid state). RAID or software volume shadowing should also be evaluated carefully since they typically improve read performance, but significantly hurt write performance.

Another consideration people often forget is steady state (i.e. when everything is running normal and renewals and new clients are being serviced) vs avalanche situations (such as when a large number of clients are coming back after a power failure or other outage). You never want to build your service so that it is near the edge in steady state since that means they'll be severely overloaded when an avalanche situation occurs (perhaps even a small one).

- Bernie

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Aug 2014 23:19:47 +0000

Hi,

Here I think is a pretty effective way of using DHCPv6 and IPv6
Neighbor Discovery to manage mobile nodes in an enterprise network:

http://www.ietf.org/id/draft-templin-aerolink-31.txt

If you are only interested in how DHCPv6 is used and don't have
time to read the entire document, check sections 3.10 and 3.14
for the DHCPv6-specific pieces.

The most interesting aspect from a DHCPv6 perspective is that AERO
assumes there may be many DHCPv6 servers sprinkled throughout the
enterprise but there is no requirement for the servers to coordinate
with one another (in fact, it is better if they don't even try). So,
the client load can be distributed to many servers based on factors
such as topological proximity, and each server can serve as a mini
mobility anchor point.

I think this could open new business opportunities for bringing
DHCPv6 services to enterprise networks. And, it doesn't even
require enterprises to move to IPv6 first, because the mechanisms
work exactly the same for managing IPv4 networks. Anyway, I just
thought it might be worth a look.

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Sat, 16 Aug 2014 08:57:57 -0400

> such as topological proximity, and each server can serve as a mini

But scalability typically isn't an issue in corporate networks, because the client load is tiny.

---

From: Bud Millwood <[email-masked]>
Date: Sun, 17 Aug 2014 00:47:04 +0200

+1 for everything here, that's our experience on the server side.
*Especially* drive speed. If you figure with 1000 leases/s sustained
throughput, that's 600k leases in 10 minutes disregarding backoff.
Depending on the configuration, the DHCP server can naturally spread
the steady-state client load over time based on its own performance.

- Bud

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 18 Aug 2014 15:38:42 +0000

Hi Ted,

> From: Ted Lemon [mailto:[email-masked]]
> Sent: Saturday, August 16, 2014 5:58 AM
> To: Templin, Fred L
> Cc: [email-masked]

That's fine, but what I am looking for is lots of AERO Servers to
spread the traffic load for forwarding lots of IP packets. Distributed
mobility management. And, I don't want the AERO Servers to have to talk
to each other or to a centralized DHCPv6 server.

So, it is better if each AERO Server also configures a DHCPv6 server,
and that the Servers not talk to each other. That way, leases are between
the Client and each Server it associates with, and there is no need for
relay agents at all.

This approach is opening new business opportunities for DHCPv6 networking
gear in enterprise networks. And, it doesn't even have to wait for the
enterprise network to transition over to IPv6 since it will handle IPv4
networks the same way.

Thanks - Fred