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 wipe some cached DUID from somewhere, since the DUID
isn't saved but is always regenerated from /etc/machine-id or from
administrator overrides.
NM will use the administrator supplied DUID if it's found in the default
lease file locations for dhclient, which
are /etc/dhclient6.leases, /var/lib/dhcp/dhclient6.leases,
/var/lib/dhclient/dhcp6.leases, or the interface/connection specific leasefile.
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.
Gene
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
