How are you doing DHCPv6 ?

Mailman List Mirror (Read Only)
1

I am wondering how people out there are using DHCPv6 to handle assigning prefixes to end users.

We have a requirement for it to be a redundant server that is centrally located. DHCPv6 will be relayed from each customer access segment.

We have been looking at using ISC dhcpd, as that is what we use for v4. However, it currently does not support any redundancy. It also does not do very much useful logging for DHCPv6 requests. Certainly not enough to keep track of users and devices.

So, my questions are:

How are you doing DHCPv6 with Prefix Delegation?

What software are you using?

When DHCPv6 with Prefix Delegation seems to be about the only way to deploy IPv6 to end users in a generic device-agnostic fashion, I am wondering why it is so difficult to find a working solution.

thanks,
-Randy

2

Mikrotik Routeros

3

You might want to give this a read:

http://www.ietf.org/id/draft-ietf-dhc-dhcpv6-redundancy-consider-02.txt

4

You might want to give this a read:

http://www.ietf.org/id/draft-ietf-dhc-dhcpv6-redundancy-consider-02.txt

That doesn't really help us if we want to deploy before that draft becomes a standard.

Are there any DHCPv6 servers currently that actually function in a fashion that is suitable for service providers?

-Randy

5

> You might want to give this a read:
>
> http://www.ietf.org/id/draft-ietf-dhc-dhcpv6-redundancy-consider-02.txt

That doesn't really help us if we want to deploy before that draft
becomes a standard.

Well, it more or less just presents options (workarounds for missing
proper HA sync).

Are there any DHCPv6 servers currently that actually function in a
fashion that is suitable for service providers?

Without specifying your requirements, that's hard to say. If you're
looking for fully state-sync'ed DHCPv6 server HA, I'm not aware of any.

Cisco unfortunately pushed that another year into the future for CNR, so
we're resorting for now to the "Split Prefixes" model described in
abovementioned draft, effectively halving our DHCPv6-PD pools and thus
exacerbates the negative effects of RIPE's overly converservative
policy (HD-Ratio 0.94) on IPv6 by effectively stealing one bit (half
the address space) just for redundancy. :frowning:

Best regards,
Daniel

6

The good news is that doubling your IP address allocation requirements for
v6 is far better than doubling v4...

7

The draft does help you, it is a BCP and does not specify a standard. It
outlines some BCPs that are usable today. I believe I tested and verified
that what I outlined works with the ISC DHCPv6 server. It also works with
other DHCPv6 servers as well.

John

8

> You might want to give this a read:
>
>
http://www.ietf.org/id/draft-ietf-dhc-dhcpv6-redundancy-consider-02.txt

That doesn't really help us if we want to deploy before that draft
becomes a standard.

Well, it more or less just presents options (workarounds for missing
proper HA sync).

[jjmb] correct. FWIW the IETF dhcwg is currently working on DHCPv6
failover/redundancy. See here for the requirements:

http://tools.ietf.org/html/draft-mrugalski-dhc-dhcpv6-failover-requirements
-00

Are there any DHCPv6 servers currently that actually function in a
fashion that is suitable for service providers?

Without specifying your requirements, that's hard to say. If you're
looking for fully state-sync'ed DHCPv6 server HA, I'm not aware of any.

[jjmb] same here, I expect a specification would be required first.

Cisco unfortunately pushed that another year into the future for CNR, so
we're resorting for now to the "Split Prefixes" model described in
abovementioned draft, effectively halving our DHCPv6-PD pools and thus
exacerbates the negative effects of RIPE's overly converservative
policy (HD-Ratio 0.94) on IPv6 by effectively stealing one bit (half
the address space) just for redundancy. :frowning:

[jjmb] we have to do what we have to do, the good news migration to a
proper failover model should be straight forward.

9

I already had the two documents up and got them mixed up when I was reading through them. I'll have to go over the link from John in detail, and see if it gives us some ways to work around the limitations in our situation.

thanks,

-Randy

10

Well, there's nothing preventing vendors to implement proprietary state
synchronization schemes like they did for DHCPv4 too. I think that "we
need to wait for the standard" is just a mere excuse. Revamping CI of
the user interface is a much higher priority these days. :slight_smile:

Best regards,
Daniel

11

Randy Carpenter <rcarpen@network1.net> writes:

I am wondering how people out there are using DHCPv6 to handle
assigning prefixes to end users.

We have a requirement for it to be a redundant server that is
centrally located.

OK, so then you've already made your choice.

Another solution is having the DHCPv6 servers distributed while keeping
the database centrally managed. This is the route the delegated prefix
will travel:

central MySQL master => local MySQL slave on each RADIUS server =>
RADIUS based per client provisioning => local DHCPv6 server running on
each access router => DHCPv6 client on customer CPE

This is about as redundant as it gets if you have multiple RADIUS
servers in multiple sites. No need for any cooperation between the
DHCPv6 servers to be fully redundant.

The only assumption is that either will the client always connect to the
same access router, or the prefix must move between the access routers
the client uses. Whether this is a deaggregation problem for you or not
depends on how those access routers can be grouped, if at all.

But that problem is really unrelated to DHCPv6

Bjørn

12

[snip]

When you say you require redundant DHCPD, what do you mean by that?
The DHCP protocol is mostly stateless, aside from offers made, which are
stored persistently in a database.

Therefore, you can cluster the DHCPD daemon, without modifications to the
ISC DHCPD
software.

There is no shortage of cluster management software that is up to the task
of keeping a service active on an active node, and keeping the service
inactive on a standby (or failed) node.

Achieving redundancy against DHCPD failure is mostly a design and
configuration question,
not a matter of "finding a DHCPD implementation" that has redundancy.

If by redundancy you mean active/active pair of servers, for load
balancing rather than failover, that implies DHCP servers with
non-overlapping pools to assign from, and is generally a much more
complicated objective to achieve with DHCP whether v4 or v6.

13

We have a requirement for it to be a redundant server that is
centrally located. DHCPv6 will be relayed from each customer access
segment.

We have been looking at using ISC dhcpd, as that is what we use for
v4. However, it currently does not support any redundancy.

[snip]

When you say you require redundant DHCPD, what do you mean by that?
The DHCP protocol is mostly stateless, aside from offers made, which
are stored persistently in a database.

Therefore, you can cluster the DHCPD daemon, without modifications to
the ISC DHCPD
software.

DHCP is certainly not stateless, which is why there is a concept of leases, which are stored in a file. You can't have 2 servers answering for the same subnet without some sort of coordination, or you would have a potential for duplicate addresses being assigned.

There is no shortage of cluster management software that is up to the
task of keeping a service active on an active node, and keeping the
service inactive on a standby (or failed) node.

Achieving redundancy against DHCPD failure is mostly a design and
configuration question,
not a matter of "finding a DHCPD implementation" that has redundancy.

If by redundancy you mean active/active pair of servers, for load
balancing rather than failover, that implies DHCP servers with
non-overlapping pools to assign from, and is generally a much more
complicated objective to achieve with DHCP whether v4 or v6.

I mean for failover, not load balancing.

The other issue we are encountering with IPv6 is that ISC DHCPD does not log very much at all for DHCPv6.

Also, we have yet to find something reliable to identify a particular client. It looks the only thing that is sent is the link local address, which is randomized on windows machines. The MAC address does not appear to ever be sent. This makes it impossible to apply any policies based on client.

-Randy

14

Randy Carpenter <rcarpen@network1.net> writes:

DHCP is certainly not stateless, which is why there is a concept of
leases, which are stored in a file. You can't have 2 servers answering
for the same subnet without some sort of coordination, or you would
have a potential for duplicate addresses being assigned.

Duplicate assignments are not a problem as long as you ensure that the
client is the same.

I.e. if the prefix delegating DHCPv6 server serves a statically assigned
prefix to an end user based on information *uniquely identifying that
user*, then you can replicate that setup to as many completely
independent DHCPv6 servers as you like. Different end users will still
not receive duplicate assignments.

But if you want the DHCPv6 server to dynamically allocate a new prefix
to each client, then you are up for problems of course. Don't see why
you would want to do that though. Redundant DHCPv6 will be only one of
many problems in such a setup.

Bjørn

15

Duplicate assignments to different clients also won't be established if your
standby server has access to an identical lease database at the moment
your clustering software determines that the primary server has failed,
kills the primary, and places the secondary in service.

A sufficiently long lease duration should also be as good as a static
lease, in that case.
Because all the important details are in the database.

You don't have to have any coordination in the DHCP software; you just in
some cases, need to exclude the DHCPD daemon from simultaneously being
active on multiple machines.

16

Several people have mentioned clustering software. Does any one have any examples of such a thing that supports v4 and v6?

We have always used the built in failover in ISC dhcpd, and it works nicely. I don't understand why they felt it would not be needed in v6.

-Randy

17

examples of clustering software.

ocf_heartbeat_anything + ocf_heartbeat_IPv6addr
http://linux-ha.org/doc/man-pages/man-pages.html

Obviously, building a DHCPD failover cluster involves some scripting and
significant design considerations, but as far as clusters go, DNS and
DHCPD failover clusters are very simple.

And don't require special application support to achieve redundancy,
unlike, say Firewalls, SQL, FTP, SMTP or HTTPD clusters, where a
requirement may exist not to drop a single TCP connection, or fail a
single query, in case of server failure.

DHCPD doesn't even use TCP connections; and some amount of automatic retry
by the client is a feature of the protocol.

Database servers, HTTP, Firewalls, etc, are "stateful services", because
there is an "in-flight" status which is not recorded in a database, and
must be preserved by the application itself for graceful failover.

If the Firewall connection table is not synchronized online, the failover
between clustered firewalls would cause a disruption in the form of lost
TCP connections, and online users will experience an immediate temporary
issue at the moment of failover.

The same for HTTP... a TCP connection dropping is a "permanent" error.
The in-flight transactions would result in the user seeing an error page.

Those are the types of applications that actually require special support
or coordination from the application itself.

Graceful DHCPD failover to deal with server issues can be achieved by
using one of the open source or commercial clustering packages, plus a
little bit of scripting.

18

This is a problem that would be nice for ISC to resolve (or another
dependable FOSS implementation).

For a while now (about 20 years I believe) we've used ISC DHCPd in a
distributed model for our public IPv4 space. In a nutshell, each DHCP
server is configured only with static assignments, their log files are
monitored (simple event correlator), and scripts are fired off to
perform tasks like new assignments against a centralized database
(MySQL). The database is responsible for keeping track of address
assignments centrally and is used to generate configuration files for
DHCPd. Dynamic updates are made using OMAPI.

Unfortunately, the ISC DHCPv6 implementation makes replicating this
impossible due to the lack of information logged.

Another problem with the ISC DHCPv6 implementation is that it doesn't
allow you to assign fixed-address information based on the DUID _and_
IAID, which becomes a problem when a host has more than one active
adapter.

The only options are hacking the source code if you feel comfortable
doing so, or waiting for ISC to make the change (if they ever plan
to).

For now, we get by with static assignments made in the database and no
dynamic allocation via DHCPv6, which does OK in a dual-stack
environment where IPv6 isn't considered necessary yet, but in the near
future that will change.

19

We have also recently realized that the DUID is pretty much completely random, and there is no way to tie the MAC address to a client. This pretty much makes it impossible to manage a large customer base.

-Randy

20

This is a problem that would be nice for ISC to resolve (or another
dependable FOSS implementation).

For a while now (about 20 years I believe) we've used ISC DHCPd in a
distributed model for our public IPv4 space. In a nutshell, each DHCP
server is configured only with static assignments, their log files are
monitored (simple event correlator), and scripts are fired off to
perform tasks like new assignments against a centralized database
(MySQL). The database is responsible for keeping track of address
assignments centrally and is used to generate configuration files for
DHCPd. Dynamic updates are made using OMAPI.

Unfortunately, the ISC DHCPv6 implementation makes replicating this
impossible due to the lack of information logged.

Another problem with the ISC DHCPv6 implementation is that it doesn't
allow you to assign fixed-address information based on the DUID _and_
IAID, which becomes a problem when a host has more than one active
adapter.

The only options are hacking the source code if you feel comfortable
doing so, or waiting for ISC to make the change (if they ever plan
to).

I can't see any request to add this feature to ISC DHCPv6 so I've opened

  27564 request for duid+iaid as selection criteria

If we don't know you need a feature we can't put it on the roadmap.