[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

DHCPv6 and MAC addresses



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



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