atom feed63 messages in org.isc.lists.dhcp-usersRE: DHCPv6 and MAC Address inclusion
FromSent OnAttachments
1 earlier message
Ted LemonJan 23, 2012 11:56 am 
scot...@trendmicro.comJan 23, 2012 12:31 pm 
Ted LemonJan 23, 2012 12:54 pm 
scot...@trendmicro.comJan 23, 2012 1:00 pm 
perl-listJan 23, 2012 1:20 pm 
scot...@trendmicro.comJan 23, 2012 1:28 pm 
Ted LemonJan 23, 2012 1:29 pm 
Ted LemonJan 23, 2012 1:30 pm 
John HascallJan 23, 2012 2:05 pm 
scot...@trendmicro.comJan 23, 2012 4:22 pm 
Ted LemonJan 24, 2012 12:06 am 
sth...@nethelp.noJan 24, 2012 12:33 am 
scot...@trendmicro.comJan 24, 2012 1:34 am 
Simon HobsonJan 24, 2012 3:09 am 
perl-listJan 24, 2012 6:27 am 
Walter Andrew ScottJan 24, 2012 6:49 am 
perl-listJan 24, 2012 6:53 am 
Casey DeccioJan 24, 2012 9:33 am 
James JalbertJan 24, 2012 9:47 am 
perl-listJan 24, 2012 10:10 am 
Walter Andrew ScottJan 24, 2012 1:43 pm 
Ted LemonJan 24, 2012 2:48 pm 
Ted LemonJan 24, 2012 2:52 pm 
scot...@trendmicro.comJan 24, 2012 2:55 pm 
scot...@trendmicro.comJan 24, 2012 3:01 pm 
Ted LemonJan 24, 2012 3:12 pm 
scot...@trendmicro.comJan 24, 2012 3:25 pm 
José QueirozJan 24, 2012 4:42 pm 
perl-listJan 24, 2012 6:39 pm 
Alex BlighJan 25, 2012 12:18 am 
sth...@nethelp.noJan 25, 2012 1:58 am 
Simon HobsonJan 25, 2012 2:05 am 
perl-listJan 25, 2012 5:51 am 
José QueirozJan 25, 2012 6:22 am 
Ted LemonJan 25, 2012 8:38 am 
perl-listJan 25, 2012 9:26 am 
Simon HobsonJan 25, 2012 10:21 am 
Michael Dean PughJan 25, 2012 12:00 pm 
scot...@trendmicro.comJan 25, 2012 12:22 pm 
scot...@trendmicro.comJan 25, 2012 12:23 pm 
perl-listJan 25, 2012 12:35 pm 
Ted LemonJan 25, 2012 12:36 pm 
Ted LemonJan 25, 2012 12:38 pm 
perl-listJan 25, 2012 12:44 pm 
Ted LemonJan 25, 2012 12:44 pm 
Ted LemonJan 25, 2012 12:50 pm 
perl-listJan 25, 2012 12:54 pm 
Ted LemonJan 25, 2012 12:55 pm 
Ted LemonJan 25, 2012 1:02 pm 
Rudy ZijlstraJan 25, 2012 1:23 pm 
12 later messages
Subject:RE: DHCPv6 and MAC Address inclusion
From:scot...@trendmicro.com (scot@trendmicro.com)
Date:Jan 24, 2012 3:01:32 pm
List:org.isc.lists.dhcp-users

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.

-----Original Message----- From: dhcp-users-bounces+scott_stone=tren@lists.isc.org
[mailto:dhcp-users-bounces+scott_stone=tren@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, <scot@trendmicro.com> <scot@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. :)