Subject: [dhcwg] DHCPv6 Hardware Option

From: perl-list <[email-masked]>
Date: Thu, 26 Jan 2012 15:34:37 -0500 (EST)

Hello, 

New to the list. Inquiring as to the current status of this document: http://tools.ietf.org/id/draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt 

I am quite interested in seeing the hardware option make a return in DHCPv6. The reasons for this are summed up quite well in this post: https://lists.isc.org/pipermail/dhcp-users/2009-March/008317.html 

Any information anyone can provide? 

Thank you!

---

From: Jarrod Johnson <[email-masked]>
Date: Fri, 27 Jan 2012 07:09:23 -0500

I agree that it would be much much more straightforward for a lot of people
if DHCPv6 were extended to allow BOOTP-like behavior.  DUID and IAID are
just not particularly ideal identifiers for some applications (they are too
open ended and it's difficult to predict the behavior of an arbitrary
client).  IAIDs are not things that can, for example, be trivially
correlated to a mac forwarding database entry on a switch.  IAIDs are
pretty much completely at the whim of the client implementation.  DUIDs can
select a number of valid forms and are almost always DUID-LLT, but LL may
have nothing to do with the link layer address used on the network (it may
use another nic or one that was replaced) and the timestamp is not
predictable.  Reload of OS or removal of a settings file completely changes
a clients DUID.

I do see it as a challenge since the horse is already out of the barn.
Don't know how you would theoretically deal with that reality other than
hoping one day the current implementations would just age out.

FWIW, I proposed DUID-UUID as it fixed my specific problem.  Since I was
specifically concerned with OS deployment case, I had the freedom to
pre-empt default OS DHCPv6 behavior and force usage of the predictable and
consistent UUID.  I think in many enterprise circumstances, this is
actually a serviceable workaround to the limitation that manages to play
within the rules of DHCPv6 as-written.  I still need to check UEFI
implementations for conformance to the 2.3.1 UEFI spec in terms of
DUID-UUID recommendation...

On Thu, Jan 26, 2012 at 3:34 PM, perl-list <[email-masked]> wrote:

> Hello,
>
> New to the list.  Inquiring as to the current status of this document:
> http://tools.ietf.org/id/draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt
>
> I am quite interested in seeing the hardware option make a return in
> DHCPv6.  The reasons for this are summed up quite well in this post:
> https://lists.isc.org/pipermail/dhcp-users/2009-March/008317.html
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>

---

From: Vincent Zimmer <[email-masked]>
Date: Fri, 27 Jan 2012 05:55:18 -0800

Regarding UEFI and IPV6, "DHCPv6 Options for Network Boot" (RFC 5970)
treats the network boot on IPV6.   The UEFI 2.3.1 specification @
www.uefi.org section 21.3.1 describes 5970 usage under moniker of
'netboot6', along w/ the treatment of the DUID-UUID (RFC 6355) by the UEFI
firmware for purposes of platform identification on the wire.     There is
an implementation of the UEFI netboot6, including RFC 5970 and 6355
support) driver code on tianocore.org in the network package, including the
underlying IPV6 Ready-Logo'd network stack sources
https://www.ipv6ready.org/db/index.php/public/logo/02-C-000590.   Some of
the Linux distro's already support the server side accommodation of
netboot6, such as the latest version of SuSE Enterprise.    The feature is
also called out in the Dec. '11
windows8-hardware-cert-requirements-system.pdf @
http://msdn.microsoft.com/library/windows/hardware/hh748188.

I've worked on various facets of the above effort (specs + code), so I am
happy to answer any additional questions.   The final clean-up now is to
ensure that the IANA-managed "processor architecture types" @
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml are
consistent and up-to-date with the latest hardware practice.

Vincent

On Fri, Jan 27, 2012 at 4:09 AM, Jarrod Johnson <
[email-masked]> wrote:

> I agree that it would be much much more straightforward for a lot of
> people if DHCPv6 were extended to allow BOOTP-like behavior.  DUID and IAID
> are just not particularly ideal identifiers for some applications (they are
> too open ended and it's difficult to predict the behavior of an arbitrary

---

From: Shwetha <[email-masked]>
Date: Mon, 30 Jan 2012 09:43:20 +0530

Regarding:
> I do see it as a challenge since the horse is already out of the barn.  Don't
know how you would theoretically deal with that > reality other than hoping one
day the current implementations would just age out.
draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00 allows for the first hop
DHCPv6-Relay agent to insert client hardware address option as it is able to
gather that information from the client frame received. This flexibility in
how this options can be learnt and inserted not only by the client but also
by a Relay agent should make it easier to adopt. Also this draft does not
propose the new option as mandatory, but in deployments that use client
hardware address as an identifier this can be readily used.

Again, since there seems to be interest  and  considerable benefit in
adopting the approach detailed in:
http://tools.ietf.org/id/draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt,
would request for review and this to be considered as a dhc work group
draft.

Thanks,
Shwetha

On 1/27/12 5:39 PM, "Jarrod Johnson" <[email-masked]>
wrote:

> I agree that it would be much much more straightforward for a lot of people if
> DHCPv6 were extended to allow BOOTP-like behavior.  DUID and IAID are just not
> particularly ideal identifiers for some applications (they are too open ended
> and it's difficult to predict the behavior of an arbitrary client).  IAIDs are
> not things that can, for example, be trivially correlated to a mac forwarding
> database entry on a switch.  IAIDs are pretty much completely at the whim of
> the client implementation.  DUIDs can select a number of valid forms and are
> almost always DUID-LLT, but LL may have nothing to do with the link layer
> address used on the network (it may use another nic or one that was replaced)
> and the timestamp is not predictable.  Reload of OS or removal of a settings
> file completely changes a clients DUID.
> 
> I do see it as a challenge since the horse is already out of the barn.  Don't
> know how you would theoretically deal with that reality other than hoping one
> day the current implementations would just age out.
> 
> specifically concerned with OS deployment case, I had the freedom to pre-empt
> default OS DHCPv6 behavior and force usage of the predictable and consistent
> UUID.  I think in many enterprise circumstances, this is actually a
> serviceable workaround to the limitation that manages to play within the rules
> of DHCPv6 as-written.  I still need to check UEFI implementations for
> conformance to the 2.3.1 UEFI spec in terms of DUID-UUID recommendation...
> 
> 
> 
>> New to the list.  Inquiring as to the current status of this
>> document: http://tools.ietf.org/id/draft-halwasia-dhc-dhcpv6-hardware-addr-op
>> t-00.txt
>> 
>> I am quite interested in seeing the hardware option make a return in DHCPv6.
>>  The reasons for this are summed up quite well in this
>> post: https://lists.isc.org/pipermail/dhcp-users/2009-March/008317.html
>>