Saw yet another attempt at a solution pop up to try and deal with the lack of a MAC address in DHCPv6 messages.
I've been giving this some thought about how this should be best accomplished without requiring that host implementations of DHCPv6 be modified. Taking advantage of the relay-agent seems to be the most elegant solution: 1) Any DHCPv6 server on a local segment will already have access to the MAC address; but having a DHCPv6 server on each segment is not ideal. 2) Requests that are relayed flow through a relay-agent, which is on a device that also has access to the MAC address of the client system. Option A: RFC 6422 provides for Realy-Supplied DHCP Options, currently with one option code registered with IANA (OPTION_ERP_LOCAL_DOMAIN_NAME). You can see the list here: http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml I think the quickest solution would be: 1) Adding an RSOO for the client MAC address 2) Get vendors on board to draft and adopt a standard for it on routers, 3) Modify DHCPv6 servers to have support for MAC identification based on the MAC of the local request OR the MAC of the relayed request when the option is present. Option B: The current RELAY-FORW message already includes the link-local address of the client. Perhaps there should be a modification to the privacy extensions RFC to forbid the use of privacy addressing on the link-local scope; at this point we could modify DHCPv6 servers to be able to determine the MAC address for relayed requests based on their link-local address. Unfortunately, the cat is out of the bag on this one, so it would take time to get host implementations modified. I might be overlooking something critical... thoughts? -- 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
