On 02/09/2013 04:04 PM, Pavel Simerda wrote:
Yeah, just read it. And I don't think it changes anything from the NetworkManager perspective.Cheers, Pavel
OK, here is what I wrote on the dnsmasq-discuss mailing list:
I have now examined the code. I had not realized that the duid and duid-UUID bases on /etc/machine-id code was included in 0.9.7.997 (0.9.8.0-beta2) and that I did not have to apply any patches to add this support. I am going to update to this version as soon as I complete my virtual testing to see how this all works.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.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.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.However, I suspect that there are situations where DUID-UUID is the correct solution.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?I believe that the problem is we are trying to solve two different/incompatible problems.I need to look at the new code in NetworkManager to see what is being done.
I will state again that the UUID based on the machine-id does not satisfy my need to keep the client-id the same for all installations on a system which use a particular interface.
One thing I have found is that if I disable an interface, delete the related lease file and then recreate that file with default-duid "0:3:0:1:MAC"; as the first and only line, I will get a LL client id. I was very happy that I could specify the default-duid as colon separated hex bytes rather than whatever that strange encoding the dhclient uses.
However, in other cases where i stop the interface, delete the lease file, and then restart the interface appear to me to be using LLT for the client-id. How do you get a UUID-based-on-machine-id default-duid? One thing I have yet to try is to remove an interface definition and than add it back in. Tried it, no difference.
Nope, I still do not understand how to have duid-UUID used.While I can live with manually specifying the default-duid, I would still prefer an option where the command-line "-D LL" was used.
Well, time to start testing this on real systems so I can give feedback. Gene
----- Original Message -----From: "Gene Czarcinski" <[email protected]> To: [email protected] Sent: Saturday, February 9, 2013 5:03:52 PM Subject: Re: fixed ipv6 address with DHCPv6 See my reply to dcbw on the dnsmasq-discuss mailing list. Gene On 02/08/2013 12:20 PM, Pavel Simerda wrote:----- Original Message -----From: "Gene Czarcinski" <[email protected]> For some time I have been having a problem attempting to have a dnsmasq server provide a system with a fixed IPv6 address. Setting an IPv4 address and identifying the system with its NIC's MAC address. But, with DHCPv6 there is no relationship defined in the standard for DHCPv6 to use the MAC.Correct. It's replaced with UUID.I tried using the system's name but that has not proven reliable. When the system and the dnsmasq server get "out of sync", it takes manual intervention to correct things. When things do work, it works fine.System's name is generally considered unreliable due to possible collisions.I looked into using the Client-ID but that "number" is based on the MAC plus time and will vary unpredictably.This has been already fixed by dcbw after long talks with me and cyphermox.Suddenly (like yesterday) I found what appears to be the solution and it is likely to have been there for some time. By default, dhclient will use LLT (Link-Layer plus Time) to define its DUID (Client-ID).We are switching to DUID-UUID from /etc/machine-id reportedly required by D-Bus (even though I can't image any reason as D-Bus is not commonly used over the network).But, there is an command-line override which can change this to LL (Link-Layer) which uses the MAC prepended with 0:3:0:1.This was the solution I originally proposed but... 1) It has some drawbacks. 2) You don't need it for normal operation. DUID-LLT saved in a disk file is stable enough for day-to-day operation. This has been solved by cyphermox even before we switched to machine-id.The important info is here: http://tools.ietf.org/html/rfc3315#section-9.4See: * http://tools.ietf.org/html/rfc6355 for the DUID-UUID (in the form of /etc/machine-id). * https://bugzilla.gnome.org/show_bug.cgi?id=691885Also examine the dhclient man age and scroll down to "*-D*/ LL or LLT/"I admit that DUID-LL is still better than non-stored DUID-LLT but DUID-UUID proves to be a better match that the two of those. If you have specific needs, you can still override the DUID manually.I then did a quick (two line) patch to NetworkManage [src/dhcp-manager/nm-dhcp-dhclient.c] to hardcode the addition of "-D", "LL" to the command-line if it is "-6". It works as advertised.Thanks for your effort but unless there's a very good reason to use DUID-LL, we're not going to do that (but you can still override the actual DUID e.g. by a script).While this works for me, I do not propose that this be the solution in NetworkManager. Instead, I propose that the default remain the same and a new configuration file parameter be added: DUID= which will have only two valid values: LL or LLT.As UUID is now the default, this proposal is obsolete.If DUID= is not specified then the default is LLT. Once this is accepted and part of NetworkManager, I will update network-manager-applet so the the DUID value can be specified when defining an IPv6 interface. Initially, editing the configuration file should be adequate.Do you have any questions or arguments for still supporting DUID-LL when we have DUID-UUID? Cheers, Pavel_______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
_______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
