[157902] in North American Network Operators' Group
Re: DHCPv6 and MAC addresses
daemon@ATHENA.MIT.EDU (Tim Chown)
Wed Nov 14 13:04:21 2012
In-Reply-To: <CALFTrnNsiY_VqJY-ziDhomA0STev7pkjXtbwJFy_1ezPTMWang@mail.gmail.com>
From: Tim Chown <tjc@ecs.soton.ac.uk>
Date: Wed, 14 Nov 2012 18:02:35 +0000
To: Ray Soucy <rps@maine.edu>
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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@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.
>=20
> 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:=
>=20
> 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.
>=20
>=20
>=20
>=20
> Option A:
>=20
> 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:
>=20
> http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml
>=20
> I think the quickest solution would be:
>=20
> 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.
>=20
>=20
>=20
>=20
> Option B:
>=20
> 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.
>=20
> Unfortunately, the cat is out of the bag on this one, so it would take
> time to get host implementations modified.
>=20
>=20
>=20
>=20
> I might be overlooking something critical... thoughts?
>=20
>=20
>=20
>=20
> --=20
> Ray Patrick Soucy
> Network Engineer
> University of Maine System
>=20
> T: 207-561-3526
> F: 207-561-3531
>=20
> MaineREN, Maine's Research and Education Network
> www.maineren.net
>=20
