Re: [Dnsmasq-discuss] DHCPv6 and MAC
Hi Simon, Its exciting to hear that future DNSmasq versions can combine DHCPv6 with MAC adresses. We ran into the same problem with our provisioning system but I found a simple workaround which might be interesting for DNSmasq users with DHCPv6 who dont want to work with the most bleeding edge version: - Once the device has a global ipv6 address its MAC address can be accessed with neighbourhood discovery - Install ndisc6 on your system - Activate the scripting function of DNSmasq (dhcp-script) - Get the MAC address anywhere in the script with: mac=$(ndisc6 -q $3 ethXYZ | tr [:upper:] [:lower:]) - This works for all new and all old DHCP assignments - After this use the script to log data, check the MAC in databases, switch on/off firewall rules, Don't rely on the DUIDs - some systems are actually CHANGING them. Cheers, Martin Simon Kelley si...@thekelleys.org.uk hat am 4. Februar 2014 um 21:58 geschrieben: On 29/01/14 09:53, Shai Venter wrote: Hello /Simon Kelley/ Referring to http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2013q1/006818.html The thread mainly focuses on Operating System side of a IPv6 dhclient functions. But here are other aspects of the issue, more difficult to figure out: The World of UEFI IPv6 network boot agents residing on a system’s FW (a.k.a UNDI) Host Management (BMC’s) that support IPv6 For those two dhclients, an administrator’s nightmare begins in trying to understand what DUID approach was chosen by the original manufacturer ( the vendor ) And that would only go down the hill if more than one NIC exist in the system Can you please comment on that, knowing what you know on DUID approach How can a network administrator have control of the IP address assignment for specific clients, in a DHCP server/dnsmasq config, to clients of the types I described above This is just food for thought … Shai Venter, NIC FW QA engineer Mellanox Technologies LTD The whole DUID approach sucks badly when you want to provision equipment. Most times, even if there's a stable DUID associated with each piece of hardware, there's no way to enumerate that into a provisioning database ahead of actually doing the provisioning. Data-centre jockeys have managed to persuade the builders of blade systems, servers, and storage gear that they need a way to harvest hardware-IDs, after a long struggle, and what they've got is a way to harvest MAC addresses. Therefore you need to be able to provision using MAC addresses. Note that things are improving with DHCPv6, the latest release of dnsmasq _can_ associate IPv6 addresses with MAC addresses. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 and MAC
On 29/01/14 09:53, Shai Venter wrote: Hello /Simon Kelley/ Referring to http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2013q1/006818.html The thread mainly focuses on Operating System side of a IPv6 dhclient functions. But here are other aspects of the issue, more difficult to figure out: The World of UEFI IPv6 network boot agents residing on a system’s FW (a.k.a UNDI) Host Management (BMC’s) that support IPv6 For those two dhclients, an administrator’s nightmare begins in trying to understand what DUID approach was chosen by the original manufacturer ( the vendor ) And that would only go down the hill if more than one NIC exist in the system Can you please comment on that, knowing what you know on DUID approach How can a network administrator have control of the IP address assignment for specific clients, in a DHCP server/dnsmasq config, to clients of the types I described above This is just food for thought … Shai Venter, NIC FW QA engineer Mellanox Technologies LTD The whole DUID approach sucks badly when you want to provision equipment. Most times, even if there's a stable DUID associated with each piece of hardware, there's no way to enumerate that into a provisioning database ahead of actually doing the provisioning. Data-centre jockeys have managed to persuade the builders of blade systems, servers, and storage gear that they need a way to harvest hardware-IDs, after a long struggle, and what they've got is a way to harvest MAC addresses. Therefore you need to be able to provision using MAC addresses. Note that things are improving with DHCPv6, the latest release of dnsmasq _can_ associate IPv6 addresses with MAC addresses. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] DHCPv6 and MAC
Hello Simon Kelley Referring to http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2013q1/006818.html The thread mainly focuses on Operating System side of a IPv6 dhclient functions. But here are other aspects of the issue, more difficult to figure out: The World of UEFI IPv6 network boot agents residing on a system's FW (a.k.a UNDI) Host Management (BMC's) that support IPv6 For those two dhclients, an administrator's nightmare begins in trying to understand what DUID approach was chosen by the original manufacturer ( the vendor ) And that would only go down the hill if more than one NIC exist in the system Can you please comment on that, knowing what you know on DUID approach How can a network administrator have control of the IP address assignment for specific clients, in a DHCP server/dnsmasq config, to clients of the types I described above This is just food for thought ... Shai Venter, NIC FW QA engineer Mellanox Technologies LTD ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 and MAC
On 02/12/2013 09:23 AM, Gene Czarcinski wrote: On 02/11/2013 04:51 PM, Dan Williams wrote: On Mon, 2013-02-11 at 16:42 -0500, Gene Czarcinski wrote: On 02/11/2013 04:06 PM, Dan Williams wrote: Fedora 17 and 18, until 0.9.7.997, left the DUID behavior up to dhcleint, which appears to generate a default DUID itself; but the NetworkManager code will honor that existing DUID if it finds it in the interface+connection specific lease file [1]. If NM does *not*, please let me know and we'll fix that bug. It is *not*. I assume that NM is suppose to be examining the lease file before dhclient starts because it sure looks like it is dhclient that is creating the default. I have a real-hardware system that I can reboot or whatever so if you need me to test something, just tell me. I know that it is frustrating on both sides if I say there is a problem and you cannot reproduce it. If you need to see the configuration file, then I should probably open a bugzilla report and file it there. BTW, I tried putting the default-duid in /etc/dhclient.leases and also in /var/lib/dhclient.leases and the only thing that seems to work is /var/lib/NetworkManager/dhclient6-whatever.lease You want one of dhclient*6*.leases, in this priority order: SYSCONFDIR /dhclient6.leases, LOCALSTATEDIR /lib/dhcp/dhclient6.leases, LOCALSTATEDIR /lib/dhclient/dhclient6.leases, or the interface+connection-specific leasefile, eg: /var/lib/dhclient/dhclient6-cc98bcbe-ef64-4db7-9b46-b12ca02172e6-wlan12.lease When I saw the above, hand slaps forehead ... of course it should be dhclient6.leases and not dhclient.leases. So I changed it in both /etc/dhclient6.leases and /var/lib/dhclient/dhcleit6.leases but it still did not work. Only replacing the interface+connection-specific leasefile with the one line file specifying the default-duid works. However, I cannot see that as a NM problem and will need to investigate dhclient. OK, so I took a look at the dhclient code and it only looks for one dhclient6 lease file. It is either the default /var/lib/dhclient/dhclient6.leases or what is specified by the -SF command line argument such as done by NetworkManager. NetworkManager could create a new NM file such as /etc/default-duid that, if present, was use for the initial dhclient6-...lease file but dhclient will do nothing to help. From my perspective, for NetworkManager to do something like this would be useful because it could be set during the install process and the system would be configured properly from first boot. Would the NM project be receptive to a patch which implemented something like that? Gene ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 and MAC
On 02/10/2013 08:57 PM, Dan Williams wrote: Best to test with is git master or the 0.9.7.995 release. Too late ... I am running 0.9.7.997 So far things are working well (no problems). I finally figured out that the easiest way to specify the duid-default so that I would be using duid-LL is to take the colon separated hex digits and converting them to back-slash separated 3-digit octal numbers and ignore the other stuff dhclient does. This seems acceptable to dhclient. If I delete everything but the first line in the lease file and then use the above to set the LL this works. I still do not understand how/why duid-UUID gets used as the current default is duid-LLT. And, I would still like an option to specify that duid-LL be used but, if not acceptable for the regular NetworkManager distribution, then I can handle it as a local patch. Gene ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 and MAC
On Mon, 2013-02-11 at 11:48 -0500, Gene Czarcinski wrote: On 02/10/2013 08:57 PM, Dan Williams wrote: Best to test with is git master or the 0.9.7.995 release. Too late ... I am running 0.9.7.997 I lied and I actually mean 0.9.7.997 :) So far things are working well (no problems). I finally figured out that the easiest way to specify the duid-default so that I would be using duid-LL is to take the colon separated hex digits and converting them to back-slash separated 3-digit octal numbers and ignore the other stuff dhclient does. This seems acceptable to dhclient. Yep, those are the dhclient escape rules. If I delete everything but the first line in the lease file and then use the above to set the LL this works. I still do not understand how/why duid-UUID gets used as the current default is duid-LLT. And, I would still like an option to specify that duid-LL be used but, if not acceptable for the regular NetworkManager distribution, then I can handle it as a local patch. The option you're looking for *is* to set default-duid in the lease file. That's exactly how you tell NM to use the DUID you want. Otherwise, NM will generate the DUID-UUID. As I mentioned in other mails to this thread, the DUID-UUID gets used for a number of reasons (all quotes from RFC 3315): 1) the RFC specifies that the DUID is *per machine*, not per-interface, and that one DUID is used for any client run on that machine. Furthermore, the DUID must be globally unique. 2) A machine may contain more than one network interface and since under Linux, interface enumeration is not stable, there's no way to consistently choose which interface to use for the DUID-LL. Since the RFC indicates that the same DUID should be used for all interfaces (each DHCP client and server should have exactly one DUID), it's really a toss-up which interface is the main interface from which we should generate the machine-wide DUID. 3) Since the RFCs state that the DUID should not change as a result of changes to network interfaces, addition/removal of hardware, etc (a device's DUID should not change as a result of a change in the device's network hardware) this implies that it must be stored somewhere. This causes a problem when network booting or cloning system images, since a stored DUID would be used for all machines and would no longer be globally unique as required by #1. Since /etc/machine-id is already supposed to be globally unique, it must already be handled by the cloning/network-boot case, and thus we can use it as a basis for the DUID-UUID without creating extra work for the administrator. But again, you're free to override this behavior by modifying the default leasefile in /etc/dhclient6.leases with whatever DUID you desire. Dan ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 and MAC
On 02/10/2013 09:09 PM, Dan Williams wrote: On Sat, 2013-02-09 at 11:01 -0500, Gene Czarcinski wrote: snip Unfortunately, what you have done is not going to scratch my itch! First, I would like a bit of clarification. Is the DUID-UUID going to be per system or per network interface? By per system I mean that all interfaces would have the same DUID-UUID. Correct. We're working off RFC-3315, which has sections stating that the DUID used by a client or server SHOULD NOT change over time if at all possible; for example, a device's DUID should not change as a result of a change in the device's network hardware. (section 9) Which implies that even if you change a network interface, the DUID should not change. Which also implies one DUID *per machine*, not per-interface. It's also supposed to be globally unique, which means you should not use the same DUID for multiple machines or VMs (section 9). Even if we used a DUID-LL or LLT, RFC-3315 states that the DUID is generated from any one network interface that is connected to the DHCP device at the time that the DUID is generated. It doesn't say that the DHCP client process must use a separate DUID for each interface it's run on, though NM supports per-connection DUIDs. That said, you're perfectly able to put whatever DUID you want to in /etc/dhclient6.leases (or /var/lib/dhcp/dhclient6.leases or /var/lib/dhclient/dhclient6.leases) and NM will use that instead of generating a DUID-UUID. Now, what I want/need is the have a DUID which is predictable and fixed for an interface on a hardware system. The hardware system supports multi-boot of different installations such as a Fedora 17 system and a Fedora 18 system. I have a firm, learned the hard way, rule never to destroy a working systems ... all my installs are fresh installs into different partition, LVs, or btrfs-subvolumes. I want to be able to boot these system up and have them all use the same DUID. Apparently that's against RFC-3315 section 9: The motivation for having more than one type of DUID is that the DUID must be globally unique... But again, you can override with dhclient6.leases. The reason for wanting this predictable, unchanging DUID is that I want my dnsmasq server to assign this system a specific IPv6 address without having to manually configure the system. This specific IPv6 address is used for routing IPv6 address of virtual guests running on that system. I checked and /etc/machine-id differs on each installed system. For me, the DUID-UUID is no better than DUID-LLT. That's what we've got for the standards, unfortunately. But again, you're free to override this on every machine with /etc/dhclient6.leases. However, I suspect that there are situations where DUID-UUID is the correct solution. Yeah, we identified a few. Given these two different approaches/solutions, what I would like to see is to optionally do either one (on a per interface basis). If the value of DUID-UUID is kept in the interface configuration file, then maybe that could be extended so the DUID-LL could be specified (DUID-LLT is the default for dhclient if nothing else is done). How is dhclient told to use a specific DUID-UUID value? According to the standards, you're supposed to use one DUID *per machine* and that DUID must be globally unique. So what you're trying to do here apparently contravenes the standards in a couple of ways. But even so, you're certainly able to do what you want by specifying the DUID in /etc/dhclient6.leases or connection-specific lease files by putting this line in the file: default-duid your escaped DUID; And NM will happily use it; since you're the administrator, we're not forcing you to use DUID-UUID. Oops, you are correct. The standard does say one DUID per device and the same DUID for every network interface on that device. I have not tried this but what happens when you have more than on network interface and they are all connect to the same network and all using DHCPv6. If each is connected to a different network then things should work correctly. But, RFC3315 also says per device which to me means per hardware device not per OS installation. I am not sure how you do that but that is my interpretation. The only thing that comes close is duid-LL and that has a problem when there are multiple network interfaces. BTW, this whole business with client-id is because the client-id did differ between a Fedora 17 and a Fedora 18 installation which caused some things to stop working. Now, quoting a bit from RFC6355: DHCP UUIDs should be persistent across system restarts, system reconfiguration events,system software and operating system upgrades or reinstallation as well as be easily available to any part of the boot process that requires access to the DHCP UUID. And: Implementations of this specification using DUID-UUID must select a UUID that is persistent across system restart and reconfiguration events and that is available to all
Re: [Dnsmasq-discuss] DHCPv6 and MAC
On 02/11/2013 12:13 PM, Dan Williams wrote: The option you're looking for*is* to set default-duid in the lease file. That's exactly how you tell NM to use the DUID you want. Otherwise, NM will generate the DUID-UUID. See my other message. This appears to be not working. Do you want me to create a bugzilla report on this? As I mentioned in other mails to this thread, the DUID-UUID gets used for a number of reasons (all quotes from RFC 3315): 1) the RFC specifies that the DUID is*per machine*, not per-interface, and that one DUID is used for any client run on that machine. Furthermore, the DUID must be globally unique. Well, actually, I believe it says per device. Also, RFC6355 says that the only solution they consider is firmware based which /etc/machine-id is not or it would not vary between OS installs. 2) A machine may contain more than one network interface and since under Linux, interface enumeration is not stable, there's no way to consistently choose which interface to use for the DUID-LL. Since the RFC indicates that the same DUID should be used for all interfaces (each DHCP client and server should have exactly one DUID), it's really a toss-up which interface is the main interface from which we should generate the machine-wide DUID. 3) Since the RFCs state that the DUID should not change as a result of changes to network interfaces, addition/removal of hardware, etc (a device's DUID should not change as a result of a change in the device's network hardware) this implies that it must be stored somewhere. This causes a problem when network booting or cloning system images, since a stored DUID would be used for all machines and would no longer be globally unique as required by #1. Since /etc/machine-id is already supposed to be globally unique, it must already be handled by the cloning/network-boot case, and thus we can use it as a basis for the DUID-UUID without creating extra work for the administrator. But again, you're free to override this behavior by modifying the default leasefile in /etc/dhclient6.leases with whatever DUID you desire. I had considered /etc/dhclient6.leases and rejected it but I do not remember why. Now, it seems like the right solution. Since almost all my installs use kickstart, I could set this in my post-install script. I think I have beaten this dead horse more than enough. Gene ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 and MAC
On Mon, 2013-02-11 at 15:34 -0500, Gene Czarcinski wrote: On 02/10/2013 09:09 PM, Dan Williams wrote: On Sat, 2013-02-09 at 11:01 -0500, Gene Czarcinski wrote: snip Unfortunately, what you have done is not going to scratch my itch! First, I would like a bit of clarification. Is the DUID-UUID going to be per system or per network interface? By per system I mean that all interfaces would have the same DUID-UUID. Correct. We're working off RFC-3315, which has sections stating that the DUID used by a client or server SHOULD NOT change over time if at all possible; for example, a device's DUID should not change as a result of a change in the device's network hardware. (section 9) Which implies that even if you change a network interface, the DUID should not change. Which also implies one DUID *per machine*, not per-interface. It's also supposed to be globally unique, which means you should not use the same DUID for multiple machines or VMs (section 9). Even if we used a DUID-LL or LLT, RFC-3315 states that the DUID is generated from any one network interface that is connected to the DHCP device at the time that the DUID is generated. It doesn't say that the DHCP client process must use a separate DUID for each interface it's run on, though NM supports per-connection DUIDs. That said, you're perfectly able to put whatever DUID you want to in /etc/dhclient6.leases (or /var/lib/dhcp/dhclient6.leases or /var/lib/dhclient/dhclient6.leases) and NM will use that instead of generating a DUID-UUID. Now, what I want/need is the have a DUID which is predictable and fixed for an interface on a hardware system. The hardware system supports multi-boot of different installations such as a Fedora 17 system and a Fedora 18 system. I have a firm, learned the hard way, rule never to destroy a working systems ... all my installs are fresh installs into different partition, LVs, or btrfs-subvolumes. I want to be able to boot these system up and have them all use the same DUID. Apparently that's against RFC-3315 section 9: The motivation for having more than one type of DUID is that the DUID must be globally unique... But again, you can override with dhclient6.leases. The reason for wanting this predictable, unchanging DUID is that I want my dnsmasq server to assign this system a specific IPv6 address without having to manually configure the system. This specific IPv6 address is used for routing IPv6 address of virtual guests running on that system. I checked and /etc/machine-id differs on each installed system. For me, the DUID-UUID is no better than DUID-LLT. That's what we've got for the standards, unfortunately. But again, you're free to override this on every machine with /etc/dhclient6.leases. However, I suspect that there are situations where DUID-UUID is the correct solution. Yeah, we identified a few. Given these two different approaches/solutions, what I would like to see is to optionally do either one (on a per interface basis). If the value of DUID-UUID is kept in the interface configuration file, then maybe that could be extended so the DUID-LL could be specified (DUID-LLT is the default for dhclient if nothing else is done). How is dhclient told to use a specific DUID-UUID value? According to the standards, you're supposed to use one DUID *per machine* and that DUID must be globally unique. So what you're trying to do here apparently contravenes the standards in a couple of ways. But even so, you're certainly able to do what you want by specifying the DUID in /etc/dhclient6.leases or connection-specific lease files by putting this line in the file: default-duid your escaped DUID; And NM will happily use it; since you're the administrator, we're not forcing you to use DUID-UUID. Oops, you are correct. The standard does say one DUID per device and the same DUID for every network interface on that device. I have not tried this but what happens when you have more than on network interface and they are all connect to the same network and all using DHCPv6. If each is connected to a different network then things should work correctly. But, RFC3315 also says per device which to me means per hardware device not per OS installation. I am not sure how you do that but that is my interpretation. The only thing that comes close is duid-LL and that has a problem when there are multiple network interfaces. BTW, this whole business with client-id is because the client-id did differ between a Fedora 17 and a Fedora 18 installation which caused some things to stop working. Fedora 17 and 18, until 0.9.7.997, left the DUID behavior up to dhcleint, which appears to generate a default DUID itself; but the NetworkManager code will honor that existing DUID if it finds it in the interface+connection specific lease file [1]. If NM does *not*, please let
Re: [Dnsmasq-discuss] DHCPv6 and MAC
On Mon, 2013-02-11 at 15:46 -0500, Gene Czarcinski wrote: On 02/11/2013 12:13 PM, Dan Williams wrote: The option you're looking for*is* to set default-duid in the lease file. That's exactly how you tell NM to use the DUID you want. Otherwise, NM will generate the DUID-UUID. See my other message. This appears to be not working. Do you want me to create a bugzilla report on this? As I mentioned in other mails to this thread, the DUID-UUID gets used for a number of reasons (all quotes from RFC 3315): 1) the RFC specifies that the DUID is*per machine*, not per-interface, and that one DUID is used for any client run on that machine. Furthermore, the DUID must be globally unique. Well, actually, I believe it says per device. Also, RFC6355 says that the only solution they consider is firmware based which /etc/machine-id is not or it would not vary between OS installs. Now I see what you're saying; I think there's a case to be made for generating /etc/machine-id from whatever firmware information is available if requested by the system administrator. Essentially, machine-id *should* be the abstraction from getting that ID from CPUID, BIOS Asset Number, NVRAM, whatever. But neither NM itself nor dhclient should really be in the business of doing that. So I think we should push for getting machine-id to optionally (or even by default) generate the ID from hardware/firmware information if possible. At the moment, the only requirement that machine-id does *not* fulfill from 6355 is the OS reinstall one, so (a) it's the best we've got so far, and (b) we can work to make it more 6355-compliant. Dan 2) A machine may contain more than one network interface and since under Linux, interface enumeration is not stable, there's no way to consistently choose which interface to use for the DUID-LL. Since the RFC indicates that the same DUID should be used for all interfaces (each DHCP client and server should have exactly one DUID), it's really a toss-up which interface is the main interface from which we should generate the machine-wide DUID. 3) Since the RFCs state that the DUID should not change as a result of changes to network interfaces, addition/removal of hardware, etc (a device's DUID should not change as a result of a change in the device's network hardware) this implies that it must be stored somewhere. This causes a problem when network booting or cloning system images, since a stored DUID would be used for all machines and would no longer be globally unique as required by #1. Since /etc/machine-id is already supposed to be globally unique, it must already be handled by the cloning/network-boot case, and thus we can use it as a basis for the DUID-UUID without creating extra work for the administrator. But again, you're free to override this behavior by modifying the default leasefile in /etc/dhclient6.leases with whatever DUID you desire. I had considered /etc/dhclient6.leases and rejected it but I do not remember why. Now, it seems like the right solution. Since almost all my installs use kickstart, I could set this in my post-install script. I think I have beaten this dead horse more than enough. Gene ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 and MAC
On Mon, 2013-02-11 at 15:06 -0600, Dan Williams wrote: On Mon, 2013-02-11 at 15:34 -0500, Gene Czarcinski wrote: On 02/10/2013 09:09 PM, Dan Williams wrote: On Sat, 2013-02-09 at 11:01 -0500, Gene Czarcinski wrote: snip Unfortunately, what you have done is not going to scratch my itch! First, I would like a bit of clarification. Is the DUID-UUID going to be per system or per network interface? By per system I mean that all interfaces would have the same DUID-UUID. Correct. We're working off RFC-3315, which has sections stating that the DUID used by a client or server SHOULD NOT change over time if at all possible; for example, a device's DUID should not change as a result of a change in the device's network hardware. (section 9) Which implies that even if you change a network interface, the DUID should not change. Which also implies one DUID *per machine*, not per-interface. It's also supposed to be globally unique, which means you should not use the same DUID for multiple machines or VMs (section 9). Even if we used a DUID-LL or LLT, RFC-3315 states that the DUID is generated from any one network interface that is connected to the DHCP device at the time that the DUID is generated. It doesn't say that the DHCP client process must use a separate DUID for each interface it's run on, though NM supports per-connection DUIDs. That said, you're perfectly able to put whatever DUID you want to in /etc/dhclient6.leases (or /var/lib/dhcp/dhclient6.leases or /var/lib/dhclient/dhclient6.leases) and NM will use that instead of generating a DUID-UUID. Now, what I want/need is the have a DUID which is predictable and fixed for an interface on a hardware system. The hardware system supports multi-boot of different installations such as a Fedora 17 system and a Fedora 18 system. I have a firm, learned the hard way, rule never to destroy a working systems ... all my installs are fresh installs into different partition, LVs, or btrfs-subvolumes. I want to be able to boot these system up and have them all use the same DUID. Apparently that's against RFC-3315 section 9: The motivation for having more than one type of DUID is that the DUID must be globally unique... But again, you can override with dhclient6.leases. The reason for wanting this predictable, unchanging DUID is that I want my dnsmasq server to assign this system a specific IPv6 address without having to manually configure the system. This specific IPv6 address is used for routing IPv6 address of virtual guests running on that system. I checked and /etc/machine-id differs on each installed system. For me, the DUID-UUID is no better than DUID-LLT. That's what we've got for the standards, unfortunately. But again, you're free to override this on every machine with /etc/dhclient6.leases. However, I suspect that there are situations where DUID-UUID is the correct solution. Yeah, we identified a few. Given these two different approaches/solutions, what I would like to see is to optionally do either one (on a per interface basis). If the value of DUID-UUID is kept in the interface configuration file, then maybe that could be extended so the DUID-LL could be specified (DUID-LLT is the default for dhclient if nothing else is done). How is dhclient told to use a specific DUID-UUID value? According to the standards, you're supposed to use one DUID *per machine* and that DUID must be globally unique. So what you're trying to do here apparently contravenes the standards in a couple of ways. But even so, you're certainly able to do what you want by specifying the DUID in /etc/dhclient6.leases or connection-specific lease files by putting this line in the file: default-duid your escaped DUID; And NM will happily use it; since you're the administrator, we're not forcing you to use DUID-UUID. Oops, you are correct. The standard does say one DUID per device and the same DUID for every network interface on that device. I have not tried this but what happens when you have more than on network interface and they are all connect to the same network and all using DHCPv6. If each is connected to a different network then things should work correctly. But, RFC3315 also says per device which to me means per hardware device not per OS installation. I am not sure how you do that but that is my interpretation. The only thing that comes close is duid-LL and that has a problem when there are multiple network interfaces. BTW, this whole business with client-id is because the client-id did differ between a Fedora 17 and a Fedora 18 installation which caused some things to stop working. Fedora 17 and 18, until 0.9.7.997, left the DUID behavior up to dhcleint, which appears to generate a default DUID itself; but the
Re: [Dnsmasq-discuss] DHCPv6 and MAC
On Mon, 2013-02-11 at 16:29 -0500, Gene Czarcinski wrote: On 02/11/2013 04:12 PM, Dan Williams wrote: See my reply to your other mail about this; I see what you're saying now, and I think we can push for having whatever generates machine-id (often systemd) pull that information from firmware/hardware rather than generating it randomly. Success! Thank you. That does scratch my itch. So long as it does not vary, I can plug it into dnsmasq with fixed IPv6 addresses and it will work. Well, it turns out that machine-id is confusingly named, and that it's actually the install id and is meant to change whenever the OS is reinstalled. So we're kinda stuck here; either we try to follow the standards to the end of the earth and start parsing /sys/class/dmi/id/product_id (which apparently is often 1234567890) or we just go off machine-id and understand that reinstalling the OS on the same hardware will change the DUID. My believe is that using DUID-UUID generated from /etc/machine-id is more standards-compliant and less error-prone than using DUID-LL or DUID-LLT though. And, of course, it can always be overridden. Dan ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 and MAC
On 02/11/2013 04:06 PM, Dan Williams wrote: Fedora 17 and 18, until 0.9.7.997, left the DUID behavior up to dhcleint, which appears to generate a default DUID itself; but the NetworkManager code will honor that existing DUID if it finds it in the interface+connection specific lease file [1]. If NM does*not*, please let me know and we'll fix that bug. It is **not**. I assume that NM is suppose to be examining the lease file before dhclient starts because it sure looks like it is dhclient that is creating the default. I have a real-hardware system that I can reboot or whatever so if you need me to test something, just tell me. I know that it is frustrating on both sides if I say there is a problem and you cannot reproduce it. If you need to see the configuration file, then I should probably open a bugzilla report and file it there. BTW, I tried putting the default-duid in /etc/dhclient.leases and also in /var/lib/dhclient.leases and the only thing that seems to work is /var/lib/NetworkManager/dhclient6-whatever.lease ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 and MAC
On Mon, 2013-02-11 at 16:42 -0500, Gene Czarcinski wrote: On 02/11/2013 04:06 PM, Dan Williams wrote: Fedora 17 and 18, until 0.9.7.997, left the DUID behavior up to dhcleint, which appears to generate a default DUID itself; but the NetworkManager code will honor that existing DUID if it finds it in the interface+connection specific lease file [1]. If NM does *not*, please let me know and we'll fix that bug. It is *not*. I assume that NM is suppose to be examining the lease file before dhclient starts because it sure looks like it is dhclient that is creating the default. I have a real-hardware system that I can reboot or whatever so if you need me to test something, just tell me. I know that it is frustrating on both sides if I say there is a problem and you cannot reproduce it. If you need to see the configuration file, then I should probably open a bugzilla report and file it there. BTW, I tried putting the default-duid in /etc/dhclient.leases and also in /var/lib/dhclient.leases and the only thing that seems to work is /var/lib/NetworkManager/dhclient6-whatever.lease You want one of dhclient*6*.leases, in this priority order: SYSCONFDIR /dhclient6.leases, LOCALSTATEDIR /lib/dhcp/dhclient6.leases, LOCALSTATEDIR /lib/dhclient/dhclient6.leases, or the interface+connection-specific leasefile, eg: /var/lib/dhclient/dhclient6-cc98bcbe-ef64-4db7-9b46-b12ca02172e6-wlan12.lease Dan ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 and MAC
On 02/11/2013 04:35 PM, Dan Williams wrote: On Mon, 2013-02-11 at 16:29 -0500, Gene Czarcinski wrote: On 02/11/2013 04:12 PM, Dan Williams wrote: See my reply to your other mail about this; I see what you're saying now, and I think we can push for having whatever generates machine-id (often systemd) pull that information from firmware/hardware rather than generating it randomly. Success! Thank you. That does scratch my itch. So long as it does not vary, I can plug it into dnsmasq with fixed IPv6 addresses and it will work. Well, it turns out that machine-id is confusingly named, and that it's actually the install id and is meant to change whenever the OS is reinstalled. So we're kinda stuck here; either we try to follow the standards to the end of the earth and start parsing /sys/class/dmi/id/product_id (which apparently is often 1234567890) or we just go off machine-id and understand that reinstalling the OS on the same hardware will change the DUID. My believe is that using DUID-UUID generated from /etc/machine-id is more standards-compliant and less error-prone than using DUID-LL or DUID-LLT though. And, of course, it can always be overridden. Too bad. I thought this might be a solution. I really do not have multiple network interfaces on most systems and the ones that do are manually configured. So, I will just pick one( duid-LL or duid-UUID) and use it for every installation where I need to have a specific IPv6 address. Gene ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 and MAC
On Mon, 2013-02-11 at 16:53 -0500, Gene Czarcinski wrote: On 02/11/2013 04:35 PM, Dan Williams wrote: On Mon, 2013-02-11 at 16:29 -0500, Gene Czarcinski wrote: On 02/11/2013 04:12 PM, Dan Williams wrote: See my reply to your other mail about this; I see what you're saying now, and I think we can push for having whatever generates machine-id (often systemd) pull that information from firmware/hardware rather than generating it randomly. Success! Thank you. That does scratch my itch. So long as it does not vary, I can plug it into dnsmasq with fixed IPv6 addresses and it will work. Well, it turns out that machine-id is confusingly named, and that it's actually the install id and is meant to change whenever the OS is reinstalled. So we're kinda stuck here; either we try to follow the standards to the end of the earth and start parsing /sys/class/dmi/id/product_id (which apparently is often 1234567890) or we just go off machine-id and understand that reinstalling the OS on the same hardware will change the DUID. My believe is that using DUID-UUID generated from /etc/machine-id is more standards-compliant and less error-prone than using DUID-LL or DUID-LLT though. And, of course, it can always be overridden. Too bad. I thought this might be a solution. I really do not have multiple network interfaces on most systems and the ones that do are manually configured. So, I will just pick one( duid-LL or duid-UUID) and use it for every installation where I need to have a specific IPv6 address. A DUID-UUID on a system with one interface should provide exactly the same behavior as a DUID-LL on that system, no? And are the systems you run that have multiple interfaces that use DHCPv6 connected to the same broadcast domain (eg, would use the same DHCPv6 server)? Dan ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 and MAC
On Sat, 2013-02-09 at 12:02 -0500, Gene Czarcinski wrote: On 02/09/2013 11:01 AM, Gene Czarcinski wrote: I need to look at the new code in NetworkManager to see what is being done. There is a testing candidate update out for NetworkManager and networt-manager-applet (0.9.7.997) which addresses the bridge problem among other issues. I also updated my copy of the NetworkManager git and checked out the duid branch. It appears (if I did not screw something up) that there is a 4 patch difference to implement the new duid capability. Is this code OK to give it a shot? I want to understand what the new code does without spending lots of time analyzing the source code (at least not yet). We merged the DUID stuff to git master already, so any of the DUID branches are old and shouldn't be used. The code is OK to try out. My brief look at the source code tells me that there may be a way I can live with this. Plus, I need to test this with dnsmasq so to ensure that what I want does work for me. Best to test with is git master or the 0.9.7.995 release. Dan ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 and MAC
On Sat, 2013-02-09 at 11:01 -0500, Gene Czarcinski wrote: On 02/08/2013 05:11 PM, Dan Williams wrote: On Fri, 2013-02-08 at 11:34 -0500, Gene Czarcinski wrote: On 02/08/2013 10:39 AM, Gene Czarcinski wrote: On 02/08/2013 10:17 AM, Simon Kelley wrote: On 07/02/13 21:27, Gene Czarcinski wrote: On 02/07/2013 04:22 PM, Gene Czarcinski wrote: I was googling around and found this: Looks like I got it working. I must admit that I was going off of information back when IPv6 and DHCPv6 first came out. So it was my impression that in my DHCP server configuration I had to use the old style of: host-identifier option dhcp6.client-id 00:01:00:01:17:0B:B9:14:00:1D:60:B7:5F:D4; fixed-address6 FD35:4776:6804:1::1; Turns out there is now compatibility with the IPv4 style of setting fixed ip addresses where a clientid / duid isn't required and I was able to set it up as: hardware ethernet 00:0C:29:37:12:85; fixed-address6 FD35:4776:6804:2:1::1; I remember trying the previous a long time ago when hardware ethernet wasn't allowed to be used with IPv6 but it appears that has now changed. All is well now and things are finally back on track. at: https://bbs.archlinux.org/viewtopic.php?id=139567 The quoted text is comment #5 The writer claims to be using dhclient and dhcpd. The problems described are the same ones which trouble me. Has something changed with the DHCPv6 standard or did the folks at isc.org just want something that worked? I should have waited because I found what might be a slightly different solution to the problem here: http://blog.geoff.co.uk/2011/07/08/dhcpv6-surprises/ *Surprise #2: You can no longer simply use the MAC address of an interface to assign a fixed IP address via DHCP.* Unlike DHCPv4, in which the MAC address of the client interface is included in a DHCP request, DHCPv6 uses a DHCP Unique Identifier http://tools.ietf.org/html/rfc3315#section-9, or DUID, to uniquely identify the client. By default, the DUID is synthesized from the MAC address of an arbitrary interface on the host plus the system time at the moment the DUID is generated. The same DUID is then used regardless of which interface a DHCPv6 message originates from. The DUID normally persists across reboots, but if it’s deleted on the client, e.g., when a new operating system is installed, the DUID is automatically regenerated with a new time, and the server will no longer recognize it. RFC 3315 http://tools.ietf.org/html/rfc3315 prohibits using a portion of the DUID as an identifier (it must be treated as opaque), so DHCPv6 servers can’t be told to “just look at the MAC address part” of the DUID. Fortunately for those wishing to use old-style MAC addresses, there’s an alternative DUID type that let you do this. The DUID described above is a “Type 1” DUID, and is referred to as a “Link-Layer plus Time DUID”, or DUID-LLT. Many older DHCPv6 clients implement only Type 1 DUIDs. You can configure ISC DHCPv6 client to use link-layer DUIDs http://tools.ietf.org/html/rfc3315#section-9.4 (DUID-LLs), which is simply the MAC address prepended with two identifiers (the sequence “00:03:00:01”). Moreover, these can be configured on a per-interface basis in the ISC DHCP client.^3 http://blog.geoff.co.uk/2011/07/08/dhcpv6-surprises/#footnote-3 Problem solved. Now I just need to figure out how to get dhclient to use DUID-LL rather than DUID-LLT. Sadly, it ain't that easy. a DUID-LL is _generated_ using _a_ mac address, but if the machine has more than one interface, the client can use any of them, and use the same DUID for all the interfaces. Then if the MAC address is changed for any reason, the client will likely continue to use the existing DUID, not make a new one. Essentially, the MAC address is used just to ensure that the DUID is unique, not to make ide ntifying interfaces/machines easy. That wasn't considered necessary by the definers if IPv6. It is better than DUID-LLT. I only have one NIC which works so that may not be a problem. Plus, with NetworkManager, I believe it may still work OK since NM has a separate dhclient instance for each interface it manages ... and separate DHCPv4 and DHCPv6 instances too. Each interface will have a different MAC. But, this is a good point and I will try to test what happens. Seems to work as I expected it to. The test was of a qemu-kvm/libvirt virtual system with two NICs and the updated NetworkManager installed. 1. Each NIC on a different network but the -D LL specified ... client-ID matches the NIC 2. Both NICs on the same network and with -D LL specified ... client-ID matches the respective NIC We just updated NetworkManager to generate a *stable* DUID-UUID hashed off /etc/machine-id, which is generated once at system install/clone time, and stays the same thereafter. Thus we avoid the whole
Re: [Dnsmasq-discuss] DHCPv6 and MAC
On 02/08/2013 05:11 PM, Dan Williams wrote: On Fri, 2013-02-08 at 11:34 -0500, Gene Czarcinski wrote: On 02/08/2013 10:39 AM, Gene Czarcinski wrote: On 02/08/2013 10:17 AM, Simon Kelley wrote: On 07/02/13 21:27, Gene Czarcinski wrote: On 02/07/2013 04:22 PM, Gene Czarcinski wrote: I was googling around and found this: Looks like I got it working. I must admit that I was going off of information back when IPv6 and DHCPv6 first came out. So it was my impression that in my DHCP server configuration I had to use the old style of: host-identifier option dhcp6.client-id 00:01:00:01:17:0B:B9:14:00:1D:60:B7:5F:D4; fixed-address6 FD35:4776:6804:1::1; Turns out there is now compatibility with the IPv4 style of setting fixed ip addresses where a clientid / duid isn't required and I was able to set it up as: hardware ethernet 00:0C:29:37:12:85; fixed-address6 FD35:4776:6804:2:1::1; I remember trying the previous a long time ago when hardware ethernet wasn't allowed to be used with IPv6 but it appears that has now changed. All is well now and things are finally back on track. at: https://bbs.archlinux.org/viewtopic.php?id=139567 The quoted text is comment #5 The writer claims to be using dhclient and dhcpd. The problems described are the same ones which trouble me. Has something changed with the DHCPv6 standard or did the folks at isc.org just want something that worked? I should have waited because I found what might be a slightly different solution to the problem here: http://blog.geoff.co.uk/2011/07/08/dhcpv6-surprises/ *Surprise #2: You can no longer simply use the MAC address of an interface to assign a fixed IP address via DHCP.* Unlike DHCPv4, in which the MAC address of the client interface is included in a DHCP request, DHCPv6 uses a DHCP Unique Identifier http://tools.ietf.org/html/rfc3315#section-9, or DUID, to uniquely identify the client. By default, the DUID is synthesized from the MAC address of an arbitrary interface on the host plus the system time at the moment the DUID is generated. The same DUID is then used regardless of which interface a DHCPv6 message originates from. The DUID normally persists across reboots, but if it’s deleted on the client, e.g., when a new operating system is installed, the DUID is automatically regenerated with a new time, and the server will no longer recognize it. RFC 3315 http://tools.ietf.org/html/rfc3315 prohibits using a portion of the DUID as an identifier (it must be treated as opaque), so DHCPv6 servers can’t be told to “just look at the MAC address part” of the DUID. Fortunately for those wishing to use old-style MAC addresses, there’s an alternative DUID type that let you do this. The DUID described above is a “Type 1” DUID, and is referred to as a “Link-Layer plus Time DUID”, or DUID-LLT. Many older DHCPv6 clients implement only Type 1 DUIDs. You can configure ISC DHCPv6 client to use link-layer DUIDs http://tools.ietf.org/html/rfc3315#section-9.4 (DUID-LLs), which is simply the MAC address prepended with two identifiers (the sequence “00:03:00:01”). Moreover, these can be configured on a per-interface basis in the ISC DHCP client.^3 http://blog.geoff.co.uk/2011/07/08/dhcpv6-surprises/#footnote-3 Problem solved. Now I just need to figure out how to get dhclient to use DUID-LL rather than DUID-LLT. Sadly, it ain't that easy. a DUID-LL is _generated_ using _a_ mac address, but if the machine has more than one interface, the client can use any of them, and use the same DUID for all the interfaces. Then if the MAC address is changed for any reason, the client will likely continue to use the existing DUID, not make a new one. Essentially, the MAC address is used just to ensure that the DUID is unique, not to make ide ntifying interfaces/machines easy. That wasn't considered necessary by the definers if IPv6. It is better than DUID-LLT. I only have one NIC which works so that may not be a problem. Plus, with NetworkManager, I believe it may still work OK since NM has a separate dhclient instance for each interface it manages ... and separate DHCPv4 and DHCPv6 instances too. Each interface will have a different MAC. But, this is a good point and I will try to test what happens. Seems to work as I expected it to. The test was of a qemu-kvm/libvirt virtual system with two NICs and the updated NetworkManager installed. 1. Each NIC on a different network but the -D LL specified ... client-ID matches the NIC 2. Both NICs on the same network and with -D LL specified ... client-ID matches the respective NIC We just updated NetworkManager to generate a *stable* DUID-UUID hashed off /etc/machine-id, which is generated once at system install/clone time, and stays the same thereafter. Thus we avoid the whole issue of what MAC address to generate the DUID from (which is a problem with DUID-LL and DUID-LLT), especially if the machine has multiple network interfaces. We also preserve the ability to clone a system and not have to remember to
Re: [Dnsmasq-discuss] DHCPv6 and MAC
On 02/09/2013 11:01 AM, Gene Czarcinski wrote: I need to look at the new code in NetworkManager to see what is being done. There is a testing candidate update out for NetworkManager and networt-manager-applet (0.9.7.997) which addresses the bridge problem among other issues. I also updated my copy of the NetworkManager git and checked out the duid branch. It appears (if I did not screw something up) that there is a 4 patch difference to implement the new duid capability. Is this code OK to give it a shot? I want to understand what the new code does without spending lots of time analyzing the source code (at least not yet). My brief look at the source code tells me that there may be a way I can live with this. Plus, I need to test this with dnsmasq so to ensure that what I want does work for me. Gene ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 and MAC
On 07/02/13 21:27, Gene Czarcinski wrote: On 02/07/2013 04:22 PM, Gene Czarcinski wrote: I was googling around and found this: Looks like I got it working. I must admit that I was going off of information back when IPv6 and DHCPv6 first came out. So it was my impression that in my DHCP server configuration I had to use the old style of: host-identifier option dhcp6.client-id 00:01:00:01:17:0B:B9:14:00:1D:60:B7:5F:D4; fixed-address6 FD35:4776:6804:1::1; Turns out there is now compatibility with the IPv4 style of setting fixed ip addresses where a clientid / duid isn't required and I was able to set it up as: hardware ethernet 00:0C:29:37:12:85; fixed-address6 FD35:4776:6804:2:1::1; I remember trying the previous a long time ago when hardware ethernet wasn't allowed to be used with IPv6 but it appears that has now changed. All is well now and things are finally back on track. at: https://bbs.archlinux.org/viewtopic.php?id=139567 The quoted text is comment #5 The writer claims to be using dhclient and dhcpd. The problems described are the same ones which trouble me. Has something changed with the DHCPv6 standard or did the folks at isc.org just want something that worked? I should have waited because I found what might be a slightly different solution to the problem here: http://blog.geoff.co.uk/2011/07/08/dhcpv6-surprises/ *Surprise #2: You can no longer simply use the MAC address of an interface to assign a fixed IP address via DHCP.* Unlike DHCPv4, in which the MAC address of the client interface is included in a DHCP request, DHCPv6 uses a DHCP Unique Identifier http://tools.ietf.org/html/rfc3315#section-9, or DUID, to uniquely identify the client. By default, the DUID is synthesized from the MAC address of an arbitrary interface on the host plus the system time at the moment the DUID is generated. The same DUID is then used regardless of which interface a DHCPv6 message originates from. The DUID normally persists across reboots, but if it’s deleted on the client, e.g., when a new operating system is installed, the DUID is automatically regenerated with a new time, and the server will no longer recognize it. RFC 3315 http://tools.ietf.org/html/rfc3315 prohibits using a portion of the DUID as an identifier (it must be treated as opaque), so DHCPv6 servers can’t be told to “just look at the MAC address part” of the DUID. Fortunately for those wishing to use old-style MAC addresses, there’s an alternative DUID type that let you do this. The DUID described above is a “Type 1” DUID, and is referred to as a “Link-Layer plus Time DUID”, or DUID-LLT. Many older DHCPv6 clients implement only Type 1 DUIDs. You can configure ISC DHCPv6 client to use link-layer DUIDs http://tools.ietf.org/html/rfc3315#section-9.4 (DUID-LLs), which is simply the MAC address prepended with two identifiers (the sequence “00:03:00:01”). Moreover, these can be configured on a per-interface basis in the ISC DHCP client.^3 http://blog.geoff.co.uk/2011/07/08/dhcpv6-surprises/#footnote-3 Problem solved. Now I just need to figure out how to get dhclient to use DUID-LL rather than DUID-LLT. Sadly, it ain't that easy. a DUID-LL is _generated_ using _a_ mac address, but if the machine has more than one interface, the client can use any of them, and use the same DUID for all the interfaces. Then if the MAC address is changed for any reason, the client will likely continue to use the existing DUID, not make a new one. Essentially, the MAC address is used just to ensure that the DUID is unique, not to make ide ntifying interfaces/machines easy. That wasn't considered necessary by the definers if IPv6. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 and MAC
On 02/08/2013 10:17 AM, Simon Kelley wrote: On 07/02/13 21:27, Gene Czarcinski wrote: On 02/07/2013 04:22 PM, Gene Czarcinski wrote: I was googling around and found this: Looks like I got it working. I must admit that I was going off of information back when IPv6 and DHCPv6 first came out. So it was my impression that in my DHCP server configuration I had to use the old style of: host-identifier option dhcp6.client-id 00:01:00:01:17:0B:B9:14:00:1D:60:B7:5F:D4; fixed-address6 FD35:4776:6804:1::1; Turns out there is now compatibility with the IPv4 style of setting fixed ip addresses where a clientid / duid isn't required and I was able to set it up as: hardware ethernet 00:0C:29:37:12:85; fixed-address6 FD35:4776:6804:2:1::1; I remember trying the previous a long time ago when hardware ethernet wasn't allowed to be used with IPv6 but it appears that has now changed. All is well now and things are finally back on track. at: https://bbs.archlinux.org/viewtopic.php?id=139567 The quoted text is comment #5 The writer claims to be using dhclient and dhcpd. The problems described are the same ones which trouble me. Has something changed with the DHCPv6 standard or did the folks at isc.org just want something that worked? I should have waited because I found what might be a slightly different solution to the problem here: http://blog.geoff.co.uk/2011/07/08/dhcpv6-surprises/ *Surprise #2: You can no longer simply use the MAC address of an interface to assign a fixed IP address via DHCP.* Unlike DHCPv4, in which the MAC address of the client interface is included in a DHCP request, DHCPv6 uses a DHCP Unique Identifier http://tools.ietf.org/html/rfc3315#section-9, or DUID, to uniquely identify the client. By default, the DUID is synthesized from the MAC address of an arbitrary interface on the host plus the system time at the moment the DUID is generated. The same DUID is then used regardless of which interface a DHCPv6 message originates from. The DUID normally persists across reboots, but if it’s deleted on the client, e.g., when a new operating system is installed, the DUID is automatically regenerated with a new time, and the server will no longer recognize it. RFC 3315 http://tools.ietf.org/html/rfc3315 prohibits using a portion of the DUID as an identifier (it must be treated as opaque), so DHCPv6 servers can’t be told to “just look at the MAC address part” of the DUID. Fortunately for those wishing to use old-style MAC addresses, there’s an alternative DUID type that let you do this. The DUID described above is a “Type 1” DUID, and is referred to as a “Link-Layer plus Time DUID”, or DUID-LLT. Many older DHCPv6 clients implement only Type 1 DUIDs. You can configure ISC DHCPv6 client to use link-layer DUIDs http://tools.ietf.org/html/rfc3315#section-9.4 (DUID-LLs), which is simply the MAC address prepended with two identifiers (the sequence “00:03:00:01”). Moreover, these can be configured on a per-interface basis in the ISC DHCP client.^3 http://blog.geoff.co.uk/2011/07/08/dhcpv6-surprises/#footnote-3 Problem solved. Now I just need to figure out how to get dhclient to use DUID-LL rather than DUID-LLT. Sadly, it ain't that easy. a DUID-LL is _generated_ using _a_ mac address, but if the machine has more than one interface, the client can use any of them, and use the same DUID for all the interfaces. Then if the MAC address is changed for any reason, the client will likely continue to use the existing DUID, not make a new one. Essentially, the MAC address is used just to ensure that the DUID is unique, not to make ide ntifying interfaces/machines easy. That wasn't considered necessary by the definers if IPv6. It is better than DUID-LLT. I only have one NIC which works so that may not be a problem. Plus, with NetworkManager, I believe it may still work OK since NM has a separate dhclient instance for each interface it manages ... and separate DHCPv4 and DHCPv6 instances too. Each interface will have a different MAC. But, this is a good point and I will try to test what happens. Gene ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 and MAC
On 02/08/2013 10:39 AM, Gene Czarcinski wrote: On 02/08/2013 10:17 AM, Simon Kelley wrote: On 07/02/13 21:27, Gene Czarcinski wrote: On 02/07/2013 04:22 PM, Gene Czarcinski wrote: I was googling around and found this: Looks like I got it working. I must admit that I was going off of information back when IPv6 and DHCPv6 first came out. So it was my impression that in my DHCP server configuration I had to use the old style of: host-identifier option dhcp6.client-id 00:01:00:01:17:0B:B9:14:00:1D:60:B7:5F:D4; fixed-address6 FD35:4776:6804:1::1; Turns out there is now compatibility with the IPv4 style of setting fixed ip addresses where a clientid / duid isn't required and I was able to set it up as: hardware ethernet 00:0C:29:37:12:85; fixed-address6 FD35:4776:6804:2:1::1; I remember trying the previous a long time ago when hardware ethernet wasn't allowed to be used with IPv6 but it appears that has now changed. All is well now and things are finally back on track. at: https://bbs.archlinux.org/viewtopic.php?id=139567 The quoted text is comment #5 The writer claims to be using dhclient and dhcpd. The problems described are the same ones which trouble me. Has something changed with the DHCPv6 standard or did the folks at isc.org just want something that worked? I should have waited because I found what might be a slightly different solution to the problem here: http://blog.geoff.co.uk/2011/07/08/dhcpv6-surprises/ *Surprise #2: You can no longer simply use the MAC address of an interface to assign a fixed IP address via DHCP.* Unlike DHCPv4, in which the MAC address of the client interface is included in a DHCP request, DHCPv6 uses a DHCP Unique Identifier http://tools.ietf.org/html/rfc3315#section-9, or DUID, to uniquely identify the client. By default, the DUID is synthesized from the MAC address of an arbitrary interface on the host plus the system time at the moment the DUID is generated. The same DUID is then used regardless of which interface a DHCPv6 message originates from. The DUID normally persists across reboots, but if it’s deleted on the client, e.g., when a new operating system is installed, the DUID is automatically regenerated with a new time, and the server will no longer recognize it. RFC 3315 http://tools.ietf.org/html/rfc3315 prohibits using a portion of the DUID as an identifier (it must be treated as opaque), so DHCPv6 servers can’t be told to “just look at the MAC address part” of the DUID. Fortunately for those wishing to use old-style MAC addresses, there’s an alternative DUID type that let you do this. The DUID described above is a “Type 1” DUID, and is referred to as a “Link-Layer plus Time DUID”, or DUID-LLT. Many older DHCPv6 clients implement only Type 1 DUIDs. You can configure ISC DHCPv6 client to use link-layer DUIDs http://tools.ietf.org/html/rfc3315#section-9.4 (DUID-LLs), which is simply the MAC address prepended with two identifiers (the sequence “00:03:00:01”). Moreover, these can be configured on a per-interface basis in the ISC DHCP client.^3 http://blog.geoff.co.uk/2011/07/08/dhcpv6-surprises/#footnote-3 Problem solved. Now I just need to figure out how to get dhclient to use DUID-LL rather than DUID-LLT. Sadly, it ain't that easy. a DUID-LL is _generated_ using _a_ mac address, but if the machine has more than one interface, the client can use any of them, and use the same DUID for all the interfaces. Then if the MAC address is changed for any reason, the client will likely continue to use the existing DUID, not make a new one. Essentially, the MAC address is used just to ensure that the DUID is unique, not to make ide ntifying interfaces/machines easy. That wasn't considered necessary by the definers if IPv6. It is better than DUID-LLT. I only have one NIC which works so that may not be a problem. Plus, with NetworkManager, I believe it may still work OK since NM has a separate dhclient instance for each interface it manages ... and separate DHCPv4 and DHCPv6 instances too. Each interface will have a different MAC. But, this is a good point and I will try to test what happens. Seems to work as I expected it to. The test was of a qemu-kvm/libvirt virtual system with two NICs and the updated NetworkManager installed. 1. Each NIC on a different network but the -D LL specified ... client-ID matches the NIC 2. Both NICs on the same network and with -D LL specified ... client-ID matches the respective NIC In both cases, things worked. Gene ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 and MAC
On Fri, 2013-02-08 at 11:34 -0500, Gene Czarcinski wrote: On 02/08/2013 10:39 AM, Gene Czarcinski wrote: On 02/08/2013 10:17 AM, Simon Kelley wrote: On 07/02/13 21:27, Gene Czarcinski wrote: On 02/07/2013 04:22 PM, Gene Czarcinski wrote: I was googling around and found this: Looks like I got it working. I must admit that I was going off of information back when IPv6 and DHCPv6 first came out. So it was my impression that in my DHCP server configuration I had to use the old style of: host-identifier option dhcp6.client-id 00:01:00:01:17:0B:B9:14:00:1D:60:B7:5F:D4; fixed-address6 FD35:4776:6804:1::1; Turns out there is now compatibility with the IPv4 style of setting fixed ip addresses where a clientid / duid isn't required and I was able to set it up as: hardware ethernet 00:0C:29:37:12:85; fixed-address6 FD35:4776:6804:2:1::1; I remember trying the previous a long time ago when hardware ethernet wasn't allowed to be used with IPv6 but it appears that has now changed. All is well now and things are finally back on track. at: https://bbs.archlinux.org/viewtopic.php?id=139567 The quoted text is comment #5 The writer claims to be using dhclient and dhcpd. The problems described are the same ones which trouble me. Has something changed with the DHCPv6 standard or did the folks at isc.org just want something that worked? I should have waited because I found what might be a slightly different solution to the problem here: http://blog.geoff.co.uk/2011/07/08/dhcpv6-surprises/ *Surprise #2: You can no longer simply use the MAC address of an interface to assign a fixed IP address via DHCP.* Unlike DHCPv4, in which the MAC address of the client interface is included in a DHCP request, DHCPv6 uses a DHCP Unique Identifier http://tools.ietf.org/html/rfc3315#section-9, or DUID, to uniquely identify the client. By default, the DUID is synthesized from the MAC address of an arbitrary interface on the host plus the system time at the moment the DUID is generated. The same DUID is then used regardless of which interface a DHCPv6 message originates from. The DUID normally persists across reboots, but if it’s deleted on the client, e.g., when a new operating system is installed, the DUID is automatically regenerated with a new time, and the server will no longer recognize it. RFC 3315 http://tools.ietf.org/html/rfc3315 prohibits using a portion of the DUID as an identifier (it must be treated as opaque), so DHCPv6 servers can’t be told to “just look at the MAC address part” of the DUID. Fortunately for those wishing to use old-style MAC addresses, there’s an alternative DUID type that let you do this. The DUID described above is a “Type 1” DUID, and is referred to as a “Link-Layer plus Time DUID”, or DUID-LLT. Many older DHCPv6 clients implement only Type 1 DUIDs. You can configure ISC DHCPv6 client to use link-layer DUIDs http://tools.ietf.org/html/rfc3315#section-9.4 (DUID-LLs), which is simply the MAC address prepended with two identifiers (the sequence “00:03:00:01”). Moreover, these can be configured on a per-interface basis in the ISC DHCP client.^3 http://blog.geoff.co.uk/2011/07/08/dhcpv6-surprises/#footnote-3 Problem solved. Now I just need to figure out how to get dhclient to use DUID-LL rather than DUID-LLT. Sadly, it ain't that easy. a DUID-LL is _generated_ using _a_ mac address, but if the machine has more than one interface, the client can use any of them, and use the same DUID for all the interfaces. Then if the MAC address is changed for any reason, the client will likely continue to use the existing DUID, not make a new one. Essentially, the MAC address is used just to ensure that the DUID is unique, not to make ide ntifying interfaces/machines easy. That wasn't considered necessary by the definers if IPv6. It is better than DUID-LLT. I only have one NIC which works so that may not be a problem. Plus, with NetworkManager, I believe it may still work OK since NM has a separate dhclient instance for each interface it manages ... and separate DHCPv4 and DHCPv6 instances too. Each interface will have a different MAC. But, this is a good point and I will try to test what happens. Seems to work as I expected it to. The test was of a qemu-kvm/libvirt virtual system with two NICs and the updated NetworkManager installed. 1. Each NIC on a different network but the -D LL specified ... client-ID matches the NIC 2. Both NICs on the same network and with -D LL specified ... client-ID matches the respective NIC We just updated NetworkManager to generate a *stable* DUID-UUID hashed off /etc/machine-id, which is generated once at system install/clone time, and stays the same thereafter. Thus we avoid the whole issue of what MAC address to generate the DUID from (which is a problem with DUID-LL and DUID-LLT), especially
[Dnsmasq-discuss] DHCPv6 and MAC
I was googling around and found this: Looks like I got it working. I must admit that I was going off of information back when IPv6 and DHCPv6 first came out. So it was my impression that in my DHCP server configuration I had to use the old style of: host-identifier option dhcp6.client-id 00:01:00:01:17:0B:B9:14:00:1D:60:B7:5F:D4; fixed-address6 FD35:4776:6804:1::1; Turns out there is now compatibility with the IPv4 style of setting fixed ip addresses where a clientid / duid isn't required and I was able to set it up as: hardware ethernet 00:0C:29:37:12:85; fixed-address6 FD35:4776:6804:2:1::1; I remember trying the previous a long time ago when hardware ethernet wasn't allowed to be used with IPv6 but it appears that has now changed. All is well now and things are finally back on track. at: https://bbs.archlinux.org/viewtopic.php?id=139567 The quoted text is comment #5 The writer claims to be using dhclient and dhcpd. The problems described are the same ones which trouble me. Has something changed with the DHCPv6 standard or did the folks at isc.org just want something that worked? Gene ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 and MAC
On 02/07/2013 04:22 PM, Gene Czarcinski wrote: I was googling around and found this: Looks like I got it working. I must admit that I was going off of information back when IPv6 and DHCPv6 first came out. So it was my impression that in my DHCP server configuration I had to use the old style of: host-identifier option dhcp6.client-id 00:01:00:01:17:0B:B9:14:00:1D:60:B7:5F:D4; fixed-address6 FD35:4776:6804:1::1; Turns out there is now compatibility with the IPv4 style of setting fixed ip addresses where a clientid / duid isn't required and I was able to set it up as: hardware ethernet 00:0C:29:37:12:85; fixed-address6 FD35:4776:6804:2:1::1; I remember trying the previous a long time ago when hardware ethernet wasn't allowed to be used with IPv6 but it appears that has now changed. All is well now and things are finally back on track. at: https://bbs.archlinux.org/viewtopic.php?id=139567 The quoted text is comment #5 The writer claims to be using dhclient and dhcpd. The problems described are the same ones which trouble me. Has something changed with the DHCPv6 standard or did the folks at isc.org just want something that worked? I should have waited because I found what might be a slightly different solution to the problem here: http://blog.geoff.co.uk/2011/07/08/dhcpv6-surprises/ *Surprise #2: You can no longer simply use the MAC address of an interface to assign a fixed IP address via DHCP.* Unlike DHCPv4, in which the MAC address of the client interface is included in a DHCP request, DHCPv6 uses a DHCP Unique Identifier http://tools.ietf.org/html/rfc3315#section-9, or DUID, to uniquely identify the client. By default, the DUID is synthesized from the MAC address of an arbitrary interface on the host plus the system time at the moment the DUID is generated. The same DUID is then used regardless of which interface a DHCPv6 message originates from. The DUID normally persists across reboots, but if it’s deleted on the client, e.g., when a new operating system is installed, the DUID is automatically regenerated with a new time, and the server will no longer recognize it. RFC 3315 http://tools.ietf.org/html/rfc3315 prohibits using a portion of the DUID as an identifier (it must be treated as opaque), so DHCPv6 servers can’t be told to “just look at the MAC address part” of the DUID. Fortunately for those wishing to use old-style MAC addresses, there’s an alternative DUID type that let you do this. The DUID described above is a “Type 1” DUID, and is referred to as a “Link-Layer plus Time DUID”, or DUID-LLT. Many older DHCPv6 clients implement only Type 1 DUIDs. You can configure ISC DHCPv6 client to use link-layer DUIDs http://tools.ietf.org/html/rfc3315#section-9.4 (DUID-LLs), which is simply the MAC address prepended with two identifiers (the sequence “00:03:00:01”). Moreover, these can be configured on a per-interface basis in the ISC DHCP client.^3 http://blog.geoff.co.uk/2011/07/08/dhcpv6-surprises/#footnote-3 Problem solved. Now I just need to figure out how to get dhclient to use DUID-LL rather than DUID-LLT. Gene ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
