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
What about http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-... ? -- Tim On 14 Nov 2012, at 17:46, Ray Soucy <rps@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
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 <tjc@ecs.soton.ac.uk> wrote:
What about
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-...
?
-- Tim
On 14 Nov 2012, at 17:46, Ray Soucy <rps@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
participants (2)
-
Ray Soucy -
Tim Chown