On Tue, Jan 17, 2012 at 06:19:28PM -0500, Randy Carpenter wrote:

...

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. :-( Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

On 1/17/12 6:37 PM, "Daniel Roesen" <dr@cluenet.de> wrote:

On Tue, Jan 17, 2012 at 06:19:28PM -0500, Randy Carpenter wrote:

...

...

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

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

Best regards, Daniel

-- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

On Wed, Jan 18, 2012 at 12:31:25AM +0000, Brzozowski, John wrote:

...

...

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.

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. :) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

----- Original Message -----

On Tue, Jan 17, 2012 at 4:04 PM, Randy Carpenter < rcarpen@network1.net > wrote:

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

On Sat, Jan 21, 2012 at 7:03 AM, Bjørn Mork <bjorn@mork.no> wrote:

Randy Carpenter <rcarpen@network1.net> writes:

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

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

On Sat, Jan 21, 2012 at 1:05 PM, Randy Carpenter <rcarpen@network1.net>wrote:

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

Linux-HA, RSF-1, Oracle Solaris Cluster, Veritas cluster, are a few 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. -- -JH

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 ----- Original Message -----

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.

On Tue, Jan 17, 2012 at 5:04 PM, Randy Carpenter <rcarpen@network1.net> wrote:

...

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

-- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 ----

-- Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

One major issue is that there is no way to associate a user's MAC (for IPv4) with their DUID. I haven't been able to find a way to account for this without making the user authenticate once for IPv4, and then again for IPv6. This is cumbersome to the user. Also, in the past there have been various reason why we want to pre-authenticate a client's MAC address (mostly for game consoles, and such, which have the MAC written on the outside of the machine). How can this be done with IPv6, which the DUID is not constant? -Randy ----- Original Message -----

On Mon, 2012-01-23 at 14:44 -0500, Randy Carpenter wrote:

...

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.

Not sure about that. The DUID is not random, at least not if it is being generated according to RFC 3315, which it probably should be.

A DUID should be generated by a client[1] the first time it needs one, then be stored and never change[2]. All clients are supposed to provide a mechanism for setting the DUID to a specific value. Once generated, the DUID is indeed tied to the client unless something intervenes. In particular, a DUID is not affected by a change of NIC and is identical for all connected interfaces.

I have to confess that we are not actually doing it, but the plan[3] is to capture new DUIDs as they happen and record the address->DUID mapping in our database. That's pretty much what we do now for boxes where the MAC address is not printed on the outside! But only where we need a reservation.

The servers we use will always give the same address to the same DUID. Since we do not expect to use actual reserved addresses very much, this should be all we need. We are a) not really a large enterprise and b) not an ISP or carrier, so perhaps our needs are not the same as those you envisage.

Vendors delivering pre-installed operating systems can set up vendor-assigned unique DUIDs and print them on the box, much as MAC addresses now are.

It seems to me that DUIDs are better handles for clients than MAC addresses, but will require a change in the way people do things.

Regards, K.

[1] The algorithm for generating the DUID can include the MAC of any available interface, the time of day etc, but is supposed to be treated as opaque (RFC3315, section 9). Since RFC 3315 defines precisely how the DUIDs are to be generated, it should be very easy to extract the MAC address part, but given that the MAC address used may not actually exist on the device any more, I'm not sure that's very useful. It might be useful the first time a new DUID is seen, on the assumption that the NIC was not changed before the machine was first run. Then one could note the MAC address when provisioning the machine, and recognise the DUID of that machine when it pops up on the network. Mind you, the assumption is not foolproof.

[2] Obviously devices with no long-term storage (or no storage at al! - will use a different generation algorithm than ones that do have storage.

[2] "No battle plan survives contact with the enemy" - Helmuth von Moltke the Elder.

-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

Yes, DUID and IAID should be persistent on systems. If they are not then they are not following the RFC. Note that bad practices, though, can remove that persistence (e.g. deleting the DUID, or replicating the DUID on other systems). On Mon, Jan 23, 2012 at 5:56 PM, Karl Auer <kauer@biplane.com.au> wrote:

On Mon, 2012-01-23 at 17:26 -0500, Randy Carpenter wrote:

...

One major issue is that there is no way to associate a user's MAC (for IPv4) with their DUID. I haven't been able to find a way to account for this without making the user authenticate once for IPv4, and then again for IPv6. This is cumbersome to the user. Also, in the past there have been various reason why we want to pre-authenticate a client's MAC address (mostly for game consoles, and such, which have the MAC written on the outside of the machine). How can this be done with IPv6, which the DUID is not constant?

Perhaps I misunderstand you (or the RFCs) but it seems to me that the DUID *is* constant. Reading section 9 of RFC 3315, it's pretty clear that a DUID is generated once, according to simple rules, and does not change once it has been generated. Barring intervention, of course.

The problem is how to either find out ahead of time what DUID a client has OR how to impose a specific DUID on a client as part of provisioning it. Neither of those issues looks particularly intractable, especially if vendors start shipping with pre-configured DUIDs that are written on the boxes.

What do you mean by "authenticate"? Do you mean something like 802.1x?

Regards, K.

-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

On Mon, 2012-01-23 at 18:12 -0500, Randy Carpenter wrote:

Controlled by software = not constant.

OK - fair point. But these days many MACs can be controlled by software too. In the world of virtual computing they don't exist in hardware at all. The world hasn't ended. Examples abound of codes that are software controlled but long-lived. SSIDs and other access codes on commodity wifi routers, for example. Or licence numbers for some operating systems e.g., Windows. Written on the box, too.

It is also not likely to be something that is knowable on a piece of electronic gear that is not a PC, nor will it be something that can be printed on the outside of the device, like most today.

Well, that's not really true. There is nothing stopping OEMs shipping equipment with preconfigured DUIDs and printing those DUIDs on the side of the box or the bottom of the device or whatever. As to being "knowable", well, neither is a MAC. Short of starting up a device and seeing what MAC it uses, there is no way to know ahead of time what MAC addresses a device has unless the manufacturer was kind enough to print them on the box. Don't get me wrong; I'm not trying to be an apologist for DUIDs. But I think we do need to see the problems clearly in order to solve them. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

"You shouldn't assume a MAC isn't constant" should read "is", double negative failure. On Tue, Jan 24, 2012 at 8:49 AM, Ray Soucy <rps@maine.edu> wrote:

You shouldn't assume a MAC isn't constant.  Our students spoof their MACs all the time (thinking it will save them from getting a DMCA notice).

The RFC suggests that DUIDs are stored in non-volatile memory or that an algorithm be used that can consistently reproduce the DUID (and IAID) for a system in the absence of persistent storage.

For fixed hardware devices, I suspect most would opt for the use of DUID-LL type, which essentially the MAC with a DUID preamble, and doesn't need to be stored in memory since it's based on a MAC that can not be changed.  It would be simple to create a DUID sticker at that point, even retroactively.  I think the idea that DUID is random and getting worked up that it's not written on the side of the device is a little more FUD than fact.

There _are_ things we need to address to make DHCPv6 easier to roll out (mainly on the server side), but just making bogus nitpick attacks distracts from the real issues, IMHO.

On Mon, Jan 23, 2012 at 6:12 PM, Randy Carpenter <rcarpen@network1.net> wrote:

...

Controlled by software = not constant.

It is also not likely to be something that is knowable on a piece of electronic gear that is not a PC, nor will it be something that can be printed on the outside of the device, like most today.

-Randy

----- Original Message -----

...

Yes, DUID and IAID should be persistent on systems.  If they are not then they are not following the RFC.

Note that bad practices, though, can remove that persistence (e.g. deleting the DUID, or replicating the DUID on other systems).

On Mon, Jan 23, 2012 at 5:56 PM, Karl Auer <kauer@biplane.com.au> wrote:

...

On Mon, 2012-01-23 at 17:26 -0500, Randy Carpenter wrote:

...

One major issue is that there is no way to associate a user's MAC (for IPv4) with their DUID. I haven't been able to find a way to account for this without making the user authenticate once for IPv4, and then again for IPv6. This is cumbersome to the user. Also, in the past there have been various reason why we want to pre-authenticate a client's MAC address (mostly for game consoles, and such, which have the MAC written on the outside of the machine). How can this be done with IPv6, which the DUID is not constant?

Perhaps I misunderstand you (or the RFCs) but it seems to me that the DUID *is* constant. Reading section 9 of RFC 3315, it's pretty clear that a DUID is generated once, according to simple rules, and does not change once it has been generated. Barring intervention, of course.

The problem is how to either find out ahead of time what DUID a client has OR how to impose a specific DUID on a client as part of provisioning it. Neither of those issues looks particularly intractable, especially if vendors start shipping with pre-configured DUIDs that are written on the boxes.

What do you mean by "authenticate"? Do you mean something like 802.1x?

Regards, K.

-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

-- Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

-- Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

As we're talking about "the exception, not the rule" I'll note that the majority of systems generate their DUID based on the MAC address of their adapter. ISC DHCPd does in fact allow you to configure static assignments using MAC and will match a DUID that was generated for that MAC. Assuming the MAC of 01:23:45:67:89:ab, and a DUID of 00:03:00:01:01:23:45:67:89:ab The ISC DHCPd configuration for a static host using a DUID: ----8<---- host my-pc.example.com { host-identifier option dhcp6.client-id 00:03:00:01:01:23:45:67:89:ab; fixed-address6 2001:db8:1:2::3; } ----8<---- For a MAC: ----8<---- host my-pc.example.com { host-identifier option dhcp6.client-id 00:03:00:01:01:23:45:67:89:ab; hardware ethernet 01:23:45:67:89:ab; } ----8<---- As with DHCPd for IPv4, you can make multiple entries to support both the MAC and DUID method by using the option host-name directive for additional entries: ----8<---- host my-pc.example.com { host-identifier option dhcp6.client-id 00:03:00:01:01:23:45:67:89:ab; fixed-address6 2001:db8:1:2::3; } host my-pc.example.com-1 { option host-name "my-pc.example.com"; hardware ethernet 01:23:45:67:89:ab; fixed-address6 2001:db8:1:2::3; } ----8<---- Note that this is checking the MAC address used in DUID type 1 or type 3, not the actual MAC address of the system. What we do right now (as a transition mechanism) in our IPAM is say that if we see a DUID that is based on a known MAC, then it's probably the same host, and add the association in the database. Generating a DHCPv6 configuration file using the "hardware ethernet" directive will get the majority of systems a v6 address in a dual stack environment. On a side note, DHCPv6 isn't the only place to address concerns. Before DHCPv6 was an option, we implemented a system that polls network routers and switches for ARP tables, IPv6 neighbor tables, and MAC address tables, then throws the full association (IP, MAC, Device, Port) into a MySQL database. Data is compressed into rows with "first seen" and "last seen" timestamps to save on table sizes (along with monthly rotation of tables). This provides us with the ability to see what MAC had what IP (or IPv6) address and where it was connected. Mainly for incident response. We also poll for IPv6 routers seen to catch rogue RA, though that has mostly gone away since putting PACLs in place to filter unauthorized RA. This database allows us to make the association of IPv4 and IPv6, even in a SLAAC environment; it also provides us with the history of that association (and even logs link-local addresses). When we disable a host, the database is checked so both IPv4 and IPv6 address can be disabled. As far as DUID discovery, though. It would be nice if logging changes previously mentioned were made to ISC DHCPd so we can see the DUIDs attempting to get an address along with the MAC requesting it. On Tue, Jan 24, 2012 at 11:18 AM, Randy Carpenter <rcarpen@network1.net> wrote:

I understand that MACs can be changed/spoofed. But that is the exception, not the rule.

That isn't the biggest issue, though. The biggest issue is how to correlate the MAC and the DUID. That is the only way to properly authenticate and account for users that have both v4 and v6 (which is everyone)

I don't care if their MAC changes, if that happens, they just need to reauthenticate. But, not having any way to know what their DUID is going to be, makes it impossible to also give them v6.

-Randy

----- Original Message -----

...

"You shouldn't assume a MAC isn't constant" should read "is", double negative failure.

On Tue, Jan 24, 2012 at 8:49 AM, Ray Soucy <rps@maine.edu> wrote:

...

You shouldn't assume a MAC isn't constant.  Our students spoof their MACs all the time (thinking it will save them from getting a DMCA notice).

The RFC suggests that DUIDs are stored in non-volatile memory or that an algorithm be used that can consistently reproduce the DUID (and IAID) for a system in the absence of persistent storage.

For fixed hardware devices, I suspect most would opt for the use of DUID-LL type, which essentially the MAC with a DUID preamble, and doesn't need to be stored in memory since it's based on a MAC that can not be changed.  It would be simple to create a DUID sticker at that point, even retroactively.  I think the idea that DUID is random and getting worked up that it's not written on the side of the device is a little more FUD than fact.

There _are_ things we need to address to make DHCPv6 easier to roll out (mainly on the server side), but just making bogus nitpick attacks distracts from the real issues, IMHO.

On Mon, Jan 23, 2012 at 6:12 PM, Randy Carpenter <rcarpen@network1.net> wrote:

...

Controlled by software = not constant.

It is also not likely to be something that is knowable on a piece of electronic gear that is not a PC, nor will it be something that can be printed on the outside of the device, like most today.

-Randy

----- Original Message -----

...

Yes, DUID and IAID should be persistent on systems.  If they are not then they are not following the RFC.

Note that bad practices, though, can remove that persistence (e.g. deleting the DUID, or replicating the DUID on other systems).

On Mon, Jan 23, 2012 at 5:56 PM, Karl Auer <kauer@biplane.com.au> wrote:

...

On Mon, 2012-01-23 at 17:26 -0500, Randy Carpenter wrote: > One major issue is that there is no way to associate a user's > MAC > (for > IPv4) with their DUID. I haven't been able to find a way to > account > for this without making the user authenticate once for IPv4, > and > then > again for IPv6. This is cumbersome to the user. Also, in the > past > there have been various reason why we want to pre-authenticate > a > client's MAC address (mostly for game consoles, and such, > which > have > the MAC written on the outside of the machine). How can this > be > done > with IPv6, which the DUID is not constant?

Perhaps I misunderstand you (or the RFCs) but it seems to me that the DUID *is* constant. Reading section 9 of RFC 3315, it's pretty clear that a DUID is generated once, according to simple rules, and does not change once it has been generated. Barring intervention, of course.

The problem is how to either find out ahead of time what DUID a client has OR how to impose a specific DUID on a client as part of provisioning it. Neither of those issues looks particularly intractable, especially if vendors start shipping with pre-configured DUIDs that are written on the boxes.

What do you mean by "authenticate"? Do you mean something like 802.1x?

Regards, K.

-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

-- Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

-- Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

-- Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

The requirement of the DUID is a big hurdle to DHCPv6 adoption, I agree. Currently, a DUID can be generated in 1 of 3 ways, 2 of which include _any_ MAC address of the system at the time of generation.  After that, the DUID is stored in software. The idea is that the DUID identifies the system and the IAID identifies the interface, and that over time, the system will keep its DUID even if the network adapter changes. This is obviously different from how we use DHCP for legacy IP. There are a few problems as a result: 1. Systems that are built using disk images can all have the same DUID unless the admin takes care to remove any generated DUID on the image (already see this on Windows 7 and even Linux). 2. Networks where the MAC addresses for systems are already known can’t simply build a DHCPv6 configuration based on those MACs. If someone were to modify DHCPv6 to address these concerns, I think the easiest way to do so would be to extend DHCPv6 relay messages to include the MAC address of the system making the request (DHCPv6 servers on local sub-networks would be able to determine the MAC from the packet).  This would allow transitional DHCPv6 configurations to be built on MAC addresses rather than DUID without client modification (which is key). Perhaps this is already possible through the use of RFC 6422 (which shouldn’t break anything). I think more important, though, is a good DHCPv6 server implementation with verbose logging capabilities, and the ability to specify a DUID, DUID+IAID, or MAC for static assignments. I know there are people from ISC on-list.  It would be great to hear someone who works on DHCPd chime in. How about we start with modifying ISC DHCPd for IPv6 to have proper logging and support for configuring IAID, then work on the MAC awareness piece.  ISC DHCPd makes use of RAW sockets, so it should always have the MAC for a non-relayed request.  Then we just need to work with router vendors on adding MACs as a relay option. On Mon, Jan 23, 2012 at 2:44 PM, Randy Carpenter <rcarpen@network1.net> wrote:

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

----- Original Message -----

...

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.

On Tue, Jan 17, 2012 at 5:04 PM, Randy Carpenter <rcarpen@network1.net> wrote:

...

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

-- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 ----

-- Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

I've been trying to get an answer from Juniper on this for months. Most of the responses have been something to the effect of "I have no idea what you are talking about." I recently got an answer of "Juniper has no plans to support that." I am responsible for several small ISPs' networks, and if this was properly supported, all of their customers would have native IPv6 long ago. It boggles my mind that it took until 2013 for people to finally figure out that you need to be able to identify a device that is requesting DHCP. It is even crazier that hardware manufacturers don't seem to care. thanks, -Randy ----- On Apr 1, 2015, at 8:06 PM, Ray Soucy rps@maine.edu wrote:

[ 3 year old thread ]

So back in 2012 there was some discussion on DHCPv6 and the challenge of using a DUID in a dual-stack environment where MAC-based assignments are already happening though an IPAM.

Update on this since then:

*RFC 6939 - Client Link-Layer Address Option in DHCPv6*

Pretty much exactly what I described in 2012 in terms of leveraging RFC 6422 to do this. Thank you, Halwasia, Bhandari, and Dec @ Cisco :-)

I'd like to think my email back in 2012 influenced this, but I'm sure it didn't. ;-)

*Support in ISC DHCP 4.3.1+*

https://deepthought.isc.org/article/AA-01112/0/Newly-Pre-defined-Options-in-...

Example to add logging for this in dhcpd.conf:

log (info, concat ("Lease for ", binary-to-ascii(16,16, ":", substring(suffix(option dhcp6.ia-na, 24),0,16)), " client-linklayer-addr ",v6relay(1, (binary-to-ascii(16, 8, ":", option dhcp6.client-linklayer-addr)))));

To create static bindings based on it:

host hostname-1 { host-identifier v6relopt 1 dhcp6.client-linklayer-addr 0:1:32:8b:36:ba:ed:ab; fixed-address6 2001:db8:100::123; };

[ These examples taken from Enno Rey, link follows ]

http://www.insinuator.net/2015/02/is-rfc-6939-support-finally-here-checking-...

*Cisco Support?*

Apparently Cisco has started to support this in IOS-XE by default. I haven't had a chance to verify this yet, but I did check IOS XR and IOS and still don't see support for it.

Does anyone have details on what platforms and releases from Cisco support RFC 6939 "Option 79" so far? The only thing I can find online is reference to the Cisco uBR7200 release 12.2(33)SCI, which doesn't really help me.

On Mon, Jan 23, 2012 at 5:23 PM, Ray Soucy <rps@maine.edu> wrote:

...

The requirement of the DUID is a big hurdle to DHCPv6 adoption, I agree.

Currently, a DUID can be generated in 1 of 3 ways, 2 of which include _any_ MAC address of the system at the time of generation. After that, the DUID is stored in software.

The idea is that the DUID identifies the system and the IAID identifies the interface, and that over time, the system will keep its DUID even if the network adapter changes.

This is obviously different from how we use DHCP for legacy IP.

There are a few problems as a result:

1. Systems that are built using disk images can all have the same DUID unless the admin takes care to remove any generated DUID on the image (already see this on Windows 7 and even Linux).

2. Networks where the MAC addresses for systems are already known can't simply build a DHCPv6 configuration based on those MACs.

If someone were to modify DHCPv6 to address these concerns, I think the easiest way to do so would be to extend DHCPv6 relay messages to include the MAC address of the system making the request (DHCPv6 servers on local sub-networks would be able to determine the MAC from the packet). This would allow transitional DHCPv6 configurations to be built on MAC addresses rather than DUID without client modification (which is key).

Perhaps this is already possible through the use of RFC 6422 (which shouldn't break anything).

I think more important, though, is a good DHCPv6 server implementation with verbose logging capabilities, and the ability to specify a DUID, DUID+IAID, or MAC for static assignments.

I know there are people from ISC on-list. It would be great to hear someone who works on DHCPd chime in.

How about we start with modifying ISC DHCPd for IPv6 to have proper logging and support for configuring IAID, then work on the MAC awareness piece. ISC DHCPd makes use of RAW sockets, so it should always have the MAC for a non-relayed request. Then we just need to work with router vendors on adding MACs as a relay option.

-- Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

-- Ray Patrick Soucy Network Engineer University of Maine System

T: 207-561-3526 F: 207-561-3531

MaineREN, Maine's Research and Education Network www.maineren.net

This reminds me that we have switches that will tag DHCPv6 packets with the equallent to option 82 however ISC-DHCP has no support for it. The switch will create a DHCP packet with two options, one being the user info and the other is encapsulating the original packet. ISC-DHCP will pick the encapsulated original packet and then ignore the user info from the outer packet, so it is useless. But if the most popular server is useless, how are people doing this? Regards Baldur

Thanks, Mark. The ISC website isn't very clear on how to make such requests unless you have a support contract. Also make note of my last response to the thread on logging and MAC awareness, as it may also be worth consideration. On Mon, Jan 23, 2012 at 5:05 PM, Mark Andrews <marka@isc.org> wrote:

In message <CALFTrnMXzdoS=-B=WT1hVfgKVDrQZDZ8KonhOpgU1JoqxO9j5A@mail.gmail.com> , Ray Soucy writes:

...

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.

...

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.

On Tue, Jan 17, 2012 at 5:04 PM, Randy Carpenter <rcarpen@network1.net> wrote :

...

I am wondering how people out there are using DHCPv6 to handle assigning pr

efixes to end users.

...

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

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

ever, 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 o f 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 i t is so difficult to find a working solution.

...

thanks, -Randy

-- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 ----

-- Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/