DHCPv6 and MAC Address inclusion

scott_stone at trendmicro.com scott_stone at trendmicro.com
Tue Jan 24 09:34:47 UTC 2012


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?)

 

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.

 

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.

 

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?

 

====================

Scott Stone <scott_stone at trendmicro.com>

Manager, DCS-RD

Trend Micro, Inc. http://www.trendmicro.com

 

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 12:07 AM
To: Users of ISC DHCP
Cc: dhcp-users at lists.isc.org
Subject: Re: DHCPv6 and MAC Address inclusion

 

On Jan 23, 2012, at 10:34 PM, "scott_stone at trendmicro.com" <scott_stone at trendmicro.com> wrote:

	I've done some reading on this - the intent here was for laptops/etc that have wired and wireless cards, to get the same IP regardless.  Makes sense if you think of it that way but it destroys my datacenter use-case.  DHCPv6 was likely designed 15+ years ago like IPv6 was and by the time anyone got around to actually using IPv6 en masse (ie, 2011), it was long obsolete and hadn't had the updates/attention that IPv4/DHCPv4 got over the same time period.

 

No, that's really not the intent. If that were the intent, the DHCP client would not send an IAID. I'm one of the authors of the spec, FWIW, and it's not fifteen years old-I haven't been going to the IETF that long.   I'm interested in constructive comments, but you're just making stuff up here.   





 Still scares me that there is no "private nonroutable" block of IPv6 space.  Someone screws up an ACL somewhere and bam, private/firewalled machines (DB hosts, etc) are now exposed to the internet.

 

Again, you might want to do a bit more research before making statements like these. There are in fact address ranges that do precisely what you want here.   They are called unique local addresses, and the advantage they have is that a routing mistake doesn't break your walled garden.

 


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20120124/d62354c1/attachment.html>


More information about the dhcp-users mailing list