[ 3 year old thread ] So back in 2012 there was some discussion on DHCPv6 and the challenge of using a DUID in a dual-stack environment where MAC-based assignments are already happening though an IPAM.
Update on this since then: *RFC 6939 - Client Link-Layer Address Option in DHCPv6* Pretty much exactly what I described in 2012 in terms of leveraging RFC 6422 to do this. Thank you, Halwasia, Bhandari, and Dec @ Cisco :-) I'd like to think my email back in 2012 influenced this, but I'm sure it didn't. ;-) *Support in ISC DHCP 4.3.1+* https://deepthought.isc.org/article/AA-01112/0/Newly-Pre-defined-Options-in-DHCP-4.3.html Example to add logging for this in dhcpd.conf: log (info, concat ("Lease for ", binary-to-ascii(16,16, ":", substring(suffix(option dhcp6.ia-na, 24),0,16)), " client-linklayer-addr ",v6relay(1, (binary-to-ascii(16, 8, ":", option dhcp6.client-linklayer-addr))))); To create static bindings based on it: host hostname-1 { host-identifier v6relopt 1 dhcp6.client-linklayer-addr 0:1:32:8b:36:ba:ed:ab; fixed-address6 2001:db8:100::123; }; [ These examples taken from Enno Rey, link follows ] http://www.insinuator.net/2015/02/is-rfc-6939-support-finally-here-checking-the-implementation-of-the-client-link-layer-address-option-in-dhcpv6/ *Cisco Support?* Apparently Cisco has started to support this in IOS-XE by default. I haven't had a chance to verify this yet, but I did check IOS XR and IOS and still don't see support for it. Does anyone have details on what platforms and releases from Cisco support RFC 6939 "Option 79" so far? The only thing I can find online is reference to the Cisco uBR7200 release 12.2(33)SCI, which doesn't really help me. On Mon, Jan 23, 2012 at 5:23 PM, Ray Soucy <r...@maine.edu> wrote: > The requirement of the DUID is a big hurdle to DHCPv6 adoption, I agree. > > Currently, a DUID can be generated in 1 of 3 ways, 2 of which include > _any_ MAC address of the system at the time of generation. After > that, the DUID is stored in software. > > The idea is that the DUID identifies the system and the IAID > identifies the interface, and that over time, the system will keep its > DUID even if the network adapter changes. > > This is obviously different from how we use DHCP for legacy IP. > > There are a few problems as a result: > > 1. Systems that are built using disk images can all have the same DUID > unless the admin takes care to remove any generated DUID on the image > (already see this on Windows 7 and even Linux). > > 2. Networks where the MAC addresses for systems are already known > can't simply build a DHCPv6 configuration based on those MACs. > > If someone were to modify DHCPv6 to address these concerns, I think > the easiest way to do so would be to extend DHCPv6 relay messages to > include the MAC address of the system making the request (DHCPv6 > servers on local sub-networks would be able to determine the MAC from > the packet). This would allow transitional DHCPv6 configurations to > be built on MAC addresses rather than DUID without client modification > (which is key). > > Perhaps this is already possible through the use of RFC 6422 (which > shouldn't break anything). > > I think more important, though, is a good DHCPv6 server implementation > with verbose logging capabilities, and the ability to specify a DUID, > DUID+IAID, or MAC for static assignments. > > I know there are people from ISC on-list. It would be great to hear > someone who works on DHCPd chime in. > > How about we start with modifying ISC DHCPd for IPv6 to have proper > logging and support for configuring IAID, then work on the MAC > awareness piece. ISC DHCPd makes use of RAW sockets, so it should > always have the MAC for a non-relayed request. Then we just need to > work with router vendors on adding MACs as a relay option. > > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
