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
