<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
</head><body style="">
<div>
Hi Simon,
</div>
<div>
</div>
<div>
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:
</div>
<div>
</div>
<div>
- Once the device has a global ipv6 address its MAC address can be accessed with neighbourhood discovery
</div>
<div>
- Install ndisc6 on your system
</div>
<div>
- Activate the scripting function of DNSmasq ("dhcp-script")
</div>
<div>
- Get the MAC address anywhere in the script with: mac=$(ndisc6 -q $3 ethXYZ | tr "[:upper:]" "[:lower:]")
</div>
<div>
- This works for all "new" and all "old" DHCP assignments
</div>
<div>
- After this use the script to log data, check the MAC in databases, switch on/off firewall rules, ....
</div>
<div>
</div>
<div>
Don't rely on the DUIDs - some systems are actually CHANGING them.
</div>
<div>
</div>
<div>
Cheers,
</div>
<div>
Martin
</div>
<div>
</div>
<div>
<br />> Simon Kelley <simon@thekelleys.org.uk> hat am 4. Februar 2014 um 21:58 geschrieben:
<br />>
<br />>
<br />> On 29/01/14 09:53, Shai Venter wrote:
<br />> > Hello /Simon Kelley/
<br />> >
<br />> > Referring to
<br />> >
<br />> > http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2013q1/006818.html
<br />> >
<br />> > The thread mainly focuses on Operating System side of a IPv6 dhclient
<br />> > functions.
<br />> >
<br />> > But here are other aspects of the issue, more difficult to figure out:
<br />> >
<br />> > The World of UEFI IPv6 network boot agents residing on a system’s FW
<br />> > (a.k.a UNDI)
<br />> >
<br />> > Host Management (BMC’s) that support IPv6
<br />> >
<br />> > For those two dhclients, an administrator’s nightmare begins in trying
<br />> > to understand what DUID approach was chosen by the original manufacturer
<br />> > ( the vendor )
<br />> >
<br />> > And that would only go down the hill if more than one NIC exist in the
<br />> > system
<br />> >
<br />> > Can you please comment on that, knowing what you know on DUID approach
<br />> >
<br />> > How can a network administrator have control of the IP address
<br />> > assignment for specific clients, in a DHCP server/dnsmasq config, to
<br />> > clients of the types I described above
<br />> >
<br />> > This is just food for thought …
<br />> >
<br />> > Shai Venter,
<br />> >
<br />> > NIC FW QA engineer
<br />> >
<br />> > Mellanox Technologies LTD
<br />> >
<br />>
<br />> The whole DUID approach sucks badly when you want to provision
<br />> equipment. Most times, even if there's a stable DUID associated with
<br />> each piece of hardware, there's no way to enumerate that into a
<br />> provisioning database ahead of actually doing the provisioning.
<br />> Data-centre jockeys have managed to persuade the builders of blade
<br />> systems, servers, and storage gear that they need a way to harvest
<br />> hardware-IDs, after a long struggle, and what they've got is a way to
<br />> harvest MAC addresses. Therefore you need to be able to provision using
<br />> MAC addresses.
<br />>
<br />>
<br />> Note that things are improving with DHCPv6, the latest release of
<br />> dnsmasq _can_ associate IPv6 addresses with MAC addresses.
<br />>
<br />>
<br />>
<br />> Cheers,
<br />>
<br />> Simon.
<br />>
<br />> _______________________________________________
<br />> Dnsmasq-discuss mailing list
<br />> Dnsmasq-discuss@lists.thekelleys.org.uk
<br />> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
</div>
</body></html>