Re: fixed ipv6 address with DHCPv6

[Gene Czarcinski <gene czarc net>]

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

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" <gene czarc net>
> > To: networkmanager-list gnome org
> > 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" <gene czarc net>
> > > > 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.4
> > > See:
> > >
> > > * 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=691885
> > >
> > > > Also 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
> > networkmanager-list gnome org
> > https://mail.gnome.org/mailman/listinfo/networkmanager-list