Well I guess someone is already working on it, +1 Since this is a relay-only message, though. I think it would be better as a sub-option of RFC 6422 with a requirement that relay-agents drop the option if the client tries to source it. But, I guess it's splitting hairs.
On Wed, Nov 14, 2012 at 1:02 PM, Tim Chown <t...@ecs.soton.ac.uk> wrote: > What about > > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-03 > > ? > > -- > Tim > > On 14 Nov 2012, at 17:46, Ray Soucy <r...@maine.edu> wrote: > > 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 > -- 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