DHCPv6 and IAID+DUID or other means of selecting IPs by interface

[bardelot]

The server has only one DUID, not one per network interface. The link layer address of a (any of the available) interface is however often encoded into the DUID to guarantee uniqueness.

[jimp]

But why "each nic"? The DUID would only be the same on a single machine. You shouldn't be trying to plug multiple interfaces from the same machine into the same network, so a DUID conflict shouldn't be an issue.

We're looking into how to get the dhcpv6 daemon to go by MAC like the v4 version does. The new version of ISC DHCPD is supposed to support that but we haven't seen an example of the syntax yet.

[bardelot]

It matches the MAC address in the DUID, not the interface MAC.

host otherclient {
        # This host entry is hopefully matched if the client supplies a DUID-LL
        # or DUID-LLT containing this MAC address.
        hardware ethernet 01:00:80:a2:55:67;

        fixed-address6 3ffe:501:ffff:100::4321;
}

[jimp]

Ah, so if a client still provides the same DUID, including the mac of whatever interface it decided that should come from, then it would still be useless.

Windows 7 does that - DUID is the same. It picks one MAC address from one NIC and then sends it along. It sends a different IAID for each one though, I believe. I didn't see that mentioned exactly in the docs though, presumably there is a way to match on IAID.

[yon]

I just see get the different IAID. what's IAID?

[jimp]

Identity association identifier. If I remember right it's meant to be an extra ID over and above the DUID to differentiate interfaces.

From RFC3315:

Identity association (IA) A collection of addresses assigned to
                                a client.  Each IA has an associated
                                IAID.  A client may have more than one
                                IA assigned to it; for example, one for
                                each of its interfaces.

Identity association identifier (IAID) An identifier for an IA,
                                chosen by the client.  Each IA has an
                                IAID, which is chosen to be unique among
                                all IAIDs for IAs belonging to that
                                client.

[jimp]

FYI you can confirm an IAID on Windows by looking at "ipconfig /all" - it will show both the IAID and DUID for an interface.

[bardelot]

DHCPv6 allows in theory to configure multiple addresses and interfaces on a single host (unlike IPv4). However you may have to ask on the dhcp-users Mailinglist if it is already supported (e.g. using DUID+IAID to configure the addresses).

Edit:
Changed to DUID+IAID

[yon]

We should choose an Only and not repeat the identity identifier. For a variety of applications client.

Identity should not be repeated, whether in any environment.  ::)

[jimp]

For each client the DIUD is unique. For each interface the IAID is unique. So the only truly unique thing to use would appear to be IAID+DUID. The IAID is nowhere near long enough to be guaranteed unique across any two clients.

[yon]

@bardelot:

DHCPv6 allows in theory to configure multiple addresses and interfaces on a single host (unlike IPv4). However you may have to ask on the dhcp-users Mailinglist if it is already supported (e.g. using DUID+IAID to configure the addresses).

Edit:
Changed to DUID+IAID

I have post to that mail list now.  :)

[jimp]

@mdpugh:

I've been following the exchanges in dhcp-users@lists.isc.org and dhcwg@ietf.org for months now.  The first one is how I found this thread.  Please do not try to use the MAC address as a unique identifier for DHCPv6.  You will fundamentally break pfSense if you do and it will fly in the face of everything that has gone into DHCPv6 thus far.  The correct method is, as suggested, DUID and IAID.  I have been running IPv6 on three subnets for several months using Server 2008 as the DHCPv6 server and pfSense as the router with both Windows and FreeBSD clients.  All computers are multihomed to at least two of these subnets with no hitches on the DHCPv6 end (I still have router advertisement issues, which I hope is where you decide to focus your attention).

I would much prefer the DUID+IAID if we can find a way to make it feasible. Seeing as we already extract this info from the leases view surely there is a way to apply that to a fixed address.

@mdpugh:

The only real reason that I can discern for why people seem to want to use the MAC as a unique identifier in DHCPv6 is for provisioning; they want to know the host with this IPv4 address has that IPv6 address (and vice versa).  But I still haven't seen a sufficient reason to break DHCPv6 as it currently stands to accomplish this.

It would be nice to have a way to do that, yes, but it seems more to me that people want to use it because it's easy and familiar. You can read the MAC on a sticker on most cards but getting the DUID and IAID is not so cut and dry. Though as someone mentioned earlier in this thread the mac command for dhcpv6 seems to actually read the mac portion of the DUID so it would be worthless for distinguishing interfaces anyhow.

@mdpugh:

Incidentally, I gave an example of the syntax for IAID usage in the client configuration file in a much older post in this forum.  I've tested this, so I know it works.

It looks like the example you gave was for the dhcp6c client not the server unless I missed the post. Do you have a link?

If we can get the syntax hashed out then we just need to add another box to the GUI.

Or if it's as simple as prepending the IAID onto the DUID (we have to split them in the leases view) then it may be even easier.

[jimp]

http://osdir.com/ml/North-American-Network-Operators-Group/2012-01/msg00749.html implies it is not yet possible but a feature request now exists.

Seeing as the most current release of the ISC DHCP daemon is before that message, I highly doubt it's possible at this point in time.

[mdpugh]

Well, I'm not sure this is going into the right thread after the split but here goes.

DUID is indeed useless by itself.  The computer generates the DUID from the first NIC's MAC and the time.  If I remember correctly, for devices with fixed storage, the spec requires this method.  Don't quote me; I'll have to look it up to be sure.  From the moment of generation, the DUID is bound to the host.  You'll have to edit the registry for Windows, edit the /var/db/dhcp6c_duid file for FreeBSD (it's encrypted and I'm not positive that's the only place it's stored), or reinstall the OS to change it.  Even if you remove the NIC that was used to generate the DUID from the machine, the DUID does not change.

In Windows, each IAID is partially generated from each NIC's MAC.  The first 24 bits of the MAC become the last 24 bits of the IAID (not very ingenious since that's the manufacturer's portion of the MAC).  I have been unable to determine how the first 8 bits of the IAID are generated (although I'm about 99.9% positive I read it somewhere on the web).

I should have mentioned in the previous post that all of the machines on all of the subnets in my network are assigned reserved addresses by DHCPv6 (after all, getting a random address is easy).  They're all multihomed machines, including the DHCPv6 server which is distributing addresses on four subnets (essentially LAN, DMZ, wireless, and management), all based on DUID+IAID.

I did give client syntax in the earlier post (http://forum.pfsense.org/index.php/topic,43951.msg227931.html#msg227931).  At the time, as I remember, I couldn't find much in the way of examples for the client configuration, but there were several for the server end of things.

I confess that, having read the two threads, I'm not completely sure what the real question is, so I've got a few of my own.  The only need for the IAID in a configuration file (client or server) is for DHCPv6 reservations (addresses that persist) (right?).  Is this functionality in the pfSense DHCPv6 Server now?  I didn't think it was.  Are you going to add it if it isn't already there?

I see several mentions of the ISC distribution.  What's in there now?  I was under the impression you were using the WIDE distribution but were considering switching to ISC.  Is this correct or has something changed?  The syntax I got working was for the WIDE version, but I did experiment with ISC because Seth said that the WIDE distro used only one TCP/IP socket (problematic with multihomed computers).

[yon]

I think if we install two or more NIC in computer,then How setup static and assign ip address to each NIC or any client Terminal. maybe It is a virtual terminal or equipment.

I think we should consider the different applications and requirements. Our main purpose is in any environment, a variety of distribution does not produce conflict or duplication.

just like Authentication of a person's DNA, it is the only.

by the way, How to manage and assign an address in accordance with management purposes？For example, I which addresses is reserved not assigned.

Which addresses can be prohibited and freedom of management.
Which addresses can be assigned by group or press equipment.

such as:

2001:470:f188:15::18–25 only for A NIC or A group
2001:470:f188:15::50--100 disable for some NIC or groups.  or only for admin's some NIC.

[mdpugh]

Maybe I'm being obtuse, but I feel like I'm having to read between the lines to discern the actual nature of the problem.  Each host has one DUID which is generated from the MAC of one of its interfaces (NICs) and the date/time.  Once it is generated, it persists indefinitely even if the NIC used to generate it is removed from the machine.  Each interface has one or more IAIDs which when used in conjunction with the DUID identifies a specific interface on a specific host.  Notice I did not say "uniquely identifies."  This is because one interface can have multiple IPv6 addresses (say link-local, unique-local, unique-global, temporary, etc.) and if the client (read host: one DUID) hopes to obtain these multiple addresses from the DHCPv6 server, it must present multiple IAIDs in its request(s) for addresses.  Each DUID+IAID pair will result in a separate IPv6 address being served.

Now, this is how the RFCs read.  I personally have only assigned one unique-local IPv6 address to each interface with DHCPv6 but I do have multiple interfaces in each machine.  I used DHCPv6 reservations to make sure each interface in each machine gets the same IPv6 address every time it requests/renews.  I use NPt in pfSense to translate between unique-local addresses and unique-global addresses for internet traffic.  This works for most (but not all) protocols.

Making DHCPv6 reservations in Server 2008 is easy and isn't worth going into here.  I haven't set up a FreeBSD-based DHCPv6 server yet, but I have worked extensively with the client side.  Yesterday, I started setting up a FreeBSD DHCPv6 server to satisfy my own curiosity and hopefully to answer some of these questions.  As I said, finding client-side configuration examples was near-impossible a few months ago when I first started working on this (and I resorted to the tried-and-true method of trial-and-error to figure it out), but there seemed to be plenty of server-side stuff out there.  My only question now is: should I focus on the WIDE or the ISC version (which will pfSense use going forward)?  One thing I can say before I go any further is that both the DUID and IAID will be required for reserving IPv6 addresses.

[jimp]

We're using the ISC server, and as I mentioned, it doesn't yet have a way to specify fixed addresses by both the IAID and DUID. That's the problem.

I still don't think using the MAC is a bad idea, not sure why they keep insisting it is. Sure the DUID is the same if you swap cards, but if you reinstall the OS, or multi-boot, or PXE, each of those can have a different DUID (until everyone decides to actually put the DUID in firmware… if that ever happens...)

In this thread we are speaking of the server issue on pfSense only - not the client on pfSense.

[databeestje]

yeah, if they ship said firmware with a set duid, you have DUID conflicts, which will happen.

Compared with that, the chance of getting 2 realtek nics with the same mac is very small but still happened to me.

However, if you are a ISP and more then 1 device uses the same DUID you'll be affected a lot sooner, because the DUID can  travel across multiple networks. In the case of a a duplicate mac it's often limited to a broadcast domain and a very slim chance of conflict.

So if a run is made that all has the same DUID because it wasn't cleared during build and they ship a 100k units of those there are going to be a number of confused DHCP6 servers.

[mdpugh]

First, I'd like to qualify everything that follows as quite possibly dead wrong, and if so, I apologize in advance for wasting the time and space.

Are you sure IAIDs (and, hence, DHCPv6 reservations) are not implemented in ISC's distribution?  I got to thinking about this and it didn't make sense to me.  IAIDs have been in the spec since its inception (I'm almost positive).  Why implement part of the spec and not implement another part.  After all, there is hardly any algorithmic difference between searching a list based on one key (or a simple key) and searching it based on two keys (or a compound key).  In other words, it would have to have been omitted arbitrarily rather than because it would have required thousands of man-hours of coding and testing.

I found a posting at http://www.ietf.org/mail-archive/web/dhcwg/current/msg10320.html which was written by one of the principal developers of ISC's distro and which suggests that IAIDs are implemented in the ISC client.  Would it make sense to develop the client and not the server?  Maybe he's talking about a development version, but the post is over 28 months old.

Lastly, I downloaded dhcpv6s.c (source code to version 4.2.3-P2).  I haven't had a chance to go through it thoroughly (printed, it's 61 pages in a small font), but I can say there are numerous occurences of "iaid" and "fixed_addr" (and others which look relevant) in it.  Maybe I'm jumping the gun; further scrutiny of the code will give me answer, but I thought I'd just ask the question first.

[jimp]

@mdpugh:

Are you sure IAIDs (and, hence, DHCPv6 reservations) are not implemented in ISC's distribution?

Unless it's in the source and nowhere in the docs, I'm certain it's not in the config for setting fixed addresses. It is used for full dynamic allocation to ensure a client gets the right IPs on two interfaces from the normal pool. It's just not there for setting fixed addresses.

@mdpugh:

I got to thinking about this and it didn't make sense to me.

It doesn't make sense to me, either, but welcome to the real world ;-)

@mdpugh:

IAIDs have been in the spec since its inception (I'm almost positive).  Why implement part of the spec and not implement another part.  
I found a posting at http://www.ietf.org/mail-archive/web/dhcwg/current/msg10320.html which was written by one of the principal developers of ISC's distro and which suggests that IAIDs are implemented in the ISC client.  Would it make sense to develop the client and not the server?  Maybe he's talking about a development version, but the post is over 28 months old.

As mentioned above they are used, just not in the fixed address path.

@mdpugh:

Lastly, I downloaded dhcpv6s.c (source code to version 4.2.3-P2).  I haven't had a chance to go through it thoroughly (printed, it's 61 pages in a small font), but I can say there are numerous occurences of "iaid" and "fixed_addr" (and others which look relevant) in it.  Maybe I'm jumping the gun; further scrutiny of the code will give me answer, but I thought I'd just ask the question first.

Check the thread I linked earlier. There is quite a lengthy discussion about it being missing and it's only from January of this year. Unfortunately, ISC's bug tracker isn't public that I could find so even though we know their ticket ID (see the linked post) we have no way to check on its status/response.