DUID/IAID and other DHCPv6 notes
-
Hi,
Regarding the DUID field which currently does nothing, is the eventual intent to allow user spoofing? (This value is generated automatically when an interface is configured as a DHCPv6 client and stored in /var/db/dhcp6c_duid.) This value is unique to the host. Another value, the IAID, is unique to the interface. Both are needed to uniquely identify a host/interface pair to the DHCPv6 server (useful if using reservations). The IAID is sent to the server by configuring it in /var/etc/dhcp6c_<interfacename>.conf like this:
interface em2 {
send ia-na 805307207; # request stateful address
request domain-name-servers;
request domain-name;
script "/var/etc/dhcp6c_opt1_script.sh"; # we'd like some nameservers please
};
id-assoc na 805307207 { };In this example, <interfacename>is opt1 and the IAID is 805307207. Changing this file manually will not survive a reboot. New code needs to be added to /etc/inc/interfaces.inc to provide this functionality. Similarly, a field to enter it needs to be added to the WUI and the option to autogenerate it should be available as well. It is a 32 bit field and I know Microsoft generates the last 24 bits by copying the first 24 bits of the MAC address of the interface the IAID is applied to. I'm not sure where the first 8 bits come from (if anybody knows, I'm all ears).
I'd really like to get this working. I'm a programmer and I know I can fix this if time is the issue. If someone can get me up to speed on the pfSense architecture (at least what file does/stores what), I'll gladly give it the old college try. I'll spend 95% of the time spent adding the functionality just figuring the architecture out on my own otherwise.
On another related note, if there is yet a means using the WIDE distribution of DHCPv6 to have the client send FQDN for itself (hostname.domainname.com) and vendor class options to the server, please let me know. I'm trying to get FreeBSD clients (including pfSense) to get IPv6 addresses from a 2k8 DHCPv6 server and, so far, no luck. The Solicit goes out but no Advertisement returns. The Solicit messages appear identical to analogous Microsoft Solicits except they don't include the FQDN and vendor class options. I don't know why this should make a difference, but until I rule it out…
Anyway, my two cents and an offer of my time :)
Mike Pugh</interfacename></interfacename> -
I can add a field for the IAID field if you want to, no issue there. If you can do the testing for us.
afaik none of the dhcp6 clients send a fqdn with the request. The amount of vendor class codes are really small currently since so little is supported yet. DHCP6 is very much in it's infancy.
You need to look here, most of the existing input validation in the wui code is your guide. I always start there to get the config array I need and then proceed from there for the backend.
basically change /etc/inc/interfaces.inc interface_dhcp6c_configure()
and /usr/local/www/interfaces.php for the wui. -
Yes, please add the IAID field and I'll be glad to do the testing. As I say, I'm currently testing against an MS DHCPv6 server and I think there is an inherent incompatibility between the two distributions which may or may not have to do with the server receiving FQDN and vendor class options from the client. I'm using Wireshark to sniff and I know the Solicit message is being sent. I've already tested the DUID and IAID functionality with FreeBSD clients and I know those fields are showing up in the right places in the Solicit. But the MS server does not Advertise in response. At least, no Advertise shows up in Wireshark as it does when Solicited from a Windows client. Strangely, though, the DHCP statistics displayed by the MS server always show an equal number of Solicits and Advertises. The log file generated by the MS server only shows incoming messages (Solicits and Requests), which is equally bizarre. Sounds like a firewall issue, right? I disabled it on both machines with the same results. I have to admit, I'm stumped for now. If anybody has any ideas, please let me know. I had hoped to rule out the FQDN-and/or-vendor-class issue by spoofing a Microsoft vendor code and sending the correct FQDN. I think the ISC client does have this functionality, but then I can't use pfSense as the firewall, which is a deal-breaker.