DHCPv6 and MAC Address inclusion

[scott_stone at trendmicro.com]

the way it seems to work now (RH client + ISC DHCPD server) is:

1. system is installed
2. on firstboot, dhcpv6 client generates unique DUID and stores it (does not seem based on hardware address at all)
3. this is sent as the DUID in all client negotiations for DHCPv6

ie, out of the box, RH clients do not send per-interface unique requests, and the requests they do send are generated with random IDs that we can't know before the OS is installed and is not persistent between OS re-installs.

That's the observed behavior, anyway.

====================
Scott Stone <scott_stone at trendmicro.com>
Manager, DCS-RD
Trend Micro, Inc. http://www.trendmicro.com


-----Original Message-----
From: dhcp-users-bounces+scott_stone=trendmicro.com at lists.isc.org [mailto:dhcp-users-bounces+scott_stone=trendmicro.com at lists.isc.org] On Behalf Of Ted Lemon
Sent: Tuesday, January 24, 2012 2:53 PM
To: Users of ISC DHCP
Subject: Re: DHCPv6 and MAC Address inclusion

On Jan 24, 2012, at 4:34 AM, <scott_stone at trendmicro.com>
 <scott_stone at trendmicro.com> wrote:
> Interesting - I took the approach of learning about this through the documentation for the specific implementations that I was using (isc dhcpd, rh/centos DHCP client), and other sources including other network people that I know (sadly few of whom are super familiar with IPv6) - looks like I didn't search the correct terms, however, because searching the terms that you put forth here leads me to RFC 4193 defining fc00::/7 (this hasn't been deprecated yet, has it?)

Site local was deprecated in favor of ULA.   The main difference being that ULA doesn't have to be restricted to a "site."

> As for 'intent', I forget the original source from which I read that (I thought it was an RFC) which described exactly that case of the laptop using wireless/wired as the reason behind the host-specific DUID.  A couple months back when I posted on this list about this issue I was at the time led to believe that what I wanted to do wasn't going to be do-able (not saying that anyone explicitly said that, that was just the conclusion I eventually came to after reading everyone's replies, many of which were of the "this argument has come up before, read <this archive>" which is I believe where I got the information that I was citing... anyway it was a few months ago and I have many projects on my plate.

The two interface, one address scenario is a valid use case, but the client would have to send the same IAID on both interfaces to get that functionality.   This isn't the intended behavior of all clients; it's just a behavior that we imagined might be desirable in some situations.   I don't know of any client implementations that actually support this behavior.

> Good to know that you are in the know on this/have been for a while - hope you don't mind if I bounce further questions off of you (via this list) so that I'm not getting the information second-or-third-hand.

I definitely do not mind.

> So, then, perhaps I do not quite understand how the IAID is generated or sent to the client - looking at how isc-dhcpd works, I don't see how to programatically determine the IAID of an interface from any well-known set of information that I would have ahead of time (can that be done?) - or, even, how does the client generate an IAID/is there a specific format for it/how do I find out what it is/etc?  Is this even possible with the ISC+RH server/client setup?

You should be able to get the IAID out of the IA option.   I don't know how that's done in the ISC DHCP server, however-you'd have to talk to one of the ISC guys about that.   The IPv6 code is all stuff they added after I stopped working on the ISC server about ten years ago.   :)

_______________________________________________
dhcp-users mailing list
dhcp-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.