DHCPv6 and MAC addresses

Tim Chown tjc at ecs.soton.ac.uk
Wed Nov 14 18:02:35 UTC 2012


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 <rps at 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
> 



More information about the NANOG mailing list