Subject: Re: [dhcwg] DHCPv6 Hardware Option

From: perl-list <[email-masked]>
Date: Tue, 07 Feb 2012 08:56:49 -0500 (EST)

Can a community leader comment? Is http://tools.ietf.org/id/draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt being considered as requested by Shwetha? 

----- Original Message -----

> From: "Shwetha" <[email-masked]>
> To: "Jarrod Johnson" <[email-masked]>, "perl-list"
> <[email-masked]>
> Cc: [email-masked]
> Sent: Sunday, January 29, 2012 11:13:20 PM
> Subject: Re: [dhcwg] DHCPv6 Hardware Option

> Re: [dhcwg] DHCPv6 Hardware Option 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.
> 

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

> > > Any information anyone can provide?
> > 
> 

> > > Thank you!

> > > _______________________________________________
> > 
> 
> > > dhcwg mailing list
> > 
> 
> > > [email-masked]
> > 
> 
> > > https://www.ietf.org/mailman/listinfo/dhcwg
> > 
> 

> > _______________________________________________
> 
> > dhcwg mailing list
> 
> > [email-masked]
> 
> > https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 9 Feb 2012 13:25:16 -0600

Here are some comments on the draft itself:

I don't understand why the RFC 3315 DUID-LL type format isn't used here.
Let's not use DHCPv4-isms. So, this draft should be updated to use the
format of the DUID-LL (section 9.4 of RFC 3315). Basically, the hardware
type is 16-bits, not 8. And "chtype"?? In DHCPv4, the field is "htype".
I'd drop "[c]htype" and "chaddr" (except when mentioning the DHCPv4
equivalents). These are not really used in DHCPv6 (where we use hardware
address and link-layer address).

A more minor nit, perhaps call the option OPTION_CLIENT_LLA? (Draft
might be called Client Link-Layer Address Option).

I'd be much happier if this was ONLY a Relay Agent option. That really
as a higher level of 'trust' to the data (as that is the link-layer
address being used by the device to communicate with the relay). And, a
client might get this wrong if it is multihomed. But, I guess for things
like PXE booting, there might be reasons to have the client provide it.
In any case, servers should always prefer the Relay information over any
client provided information, so I think the following is bad and
backwards:

   If DHCPv6 Server is configured to store or use client hardware

   address, it MUST first look for the client hardware address option in

   the client DHCP message.  In case it is not found, Server SHOULD look

   for client hardware option in the RELAY-FORW message of the DHCPv6

   Relay agent closest to the client.

In section 4, I would NOT list the messages. There is little 'harm' in a
client in providing this even in an Information-Request or some future
messages. Best to not list things that are not needed and are not
exhaustive.

-          Bernie

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Shwetha Bhandari (shwethab)
Sent: Sunday, January 29, 2012 11:13 PM
To: Jarrod Johnson; perl-list
Cc: [email-masked]
Subject: Re: [dhcwg] DHCPv6 Hardware Option

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.

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

Thank you!

________________________________

---

From: [email-masked]
Date: Thu, 09 Feb 2012 20:52:40 +0100 (CET)

> I don't understand why the RFC 3315 DUID-LL type format isn't used here.

Maybe because 3315 contains very explicit language prohibiting servers
from peeking inside the DUID in any way? For the Client Hardware
Address Option we *want* the server to be able to look at the address,
obviously.

> address being used by the device to communicate with the relay).

Agree that the relay agent has a higher level of trust. Disagree that
the option should *only* be a relay agent option - that requires relay
agent implementation, which takes time. A client side implementation,
for instance if it came as part of ISC DHCP, might be quicker.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 9 Feb 2012 13:55:11 -0600

You misunderstood. I was NOT suggesting that anyone 'look' inside the
DUID. I was saying we should use DHCPv6 terminology and formats for the
data carried in your option.

That means use a 16-bit hardware type field and a link-layer address
field in the NEW option.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 09, 2012 2:53 PM
To: Bernie Volz (volz)
Cc: Shwetha Bhandari (shwethab); [email-masked];
[email-masked]; [email-masked]
Subject: Re: [dhcwg] DHCPv6 Hardware Option

Maybe because 3315 contains very explicit language prohibiting servers
from peeking inside the DUID in any way? For the Client Hardware Address
Option we *want* the server to be able to look at the address,
obviously.

---

From: Andre Kostur <[email-masked]>
Date: Thu, 9 Feb 2012 11:59:10 -0800

I think Bernie is suggesting that you take the format of DUID-LL and use it
for this option, and not to specifically peer into the actual DUID option
to find the MAC address.

I disagree with Bernie where I think the client should be able to supply
its own MAC address, but I agree with him that if this is also supplied by
the Relay Agent, the server should prefer the Relay Agent's version of the
MAC address.  The client may be operating in an environment where there are
no Relay Agents, and the server is hearing the client's multicasts directly.

-- 
 *Andre Kostur*
Senior Product Design Engineer
*P:* 604-678-2864
*E:* [email-masked]
*Toll-Free:* 1-800-877-1856

*F:* 604-678-2864
*VoIP:* sip:[email-masked]

 <http://www.incognito.com>

 <http://www.incognito.com/company/events>

---

From: [email-masked]
Date: Thu, 09 Feb 2012 21:32:08 +0100 (CET)

> data carried in your option.

I see I wasn't clear enough. I didn't think peeking inside the DUID
was suggested. I think that if the *language* from the DUID-LL
section of 3315 is used, and a reference to same section is included,
some people might think that we don't really want them to be able to
get to the hardware address after all. Should be easy enough to fix
(we *really really* want to let you look at the hardware address
now :-)

---

From: Simon Hobson <[email-masked]>
Date: Thu, 9 Feb 2012 21:50:06 +0000

Andre Kostur wrote:

>I disagree with Bernie where I think the client should be able to 
>supply its own MAC address, but I agree with him that if this is 
>also supplied by the Relay Agent, the server should prefer the Relay 
>Agent's version of the MAC address.

If you go down that route, then the client doesn't need to provide it 
at all - either the server (if on the same link) or the relay agent 
(for remote clients) would be able to extract the hardware address 
from the packet - at least for ethernet like network types.

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.

---

From: Andre Kostur <[email-masked]>
Date: Thu, 9 Feb 2012 14:05:00 -0800

What about a relay agent which doesn't know about this option?

On Thu, Feb 9, 2012 at 13:50, Simon Hobson <[email-masked]> wrote:
>
> Andre Kostur wrote:
>
>> I disagree with Bernie where I think the client should be able to supply its own MAC address, but I agree with him that if this is also supplied by the Relay Agent, the server should prefer the Relay Agent's version of the MAC address.
>
>
> If you go down that route, then the client doesn't need to provide it at all - either the server (if on the same link) or the relay agent (for remote clients) would be able to extract the hardware address from the packet - at least for ethernet like network types.
>
> --
> Simon Hobson
>

-- 
Andre Kostur

---

From: Tina TSOU <[email-masked]>
Date: Thu, 09 Feb 2012 22:51:34 +0000

Tina

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Andre Kostur
> Sent: Thursday, February 09, 2012 2:05 PM
> To: Simon Hobson
> Cc: [email-masked]
Then it will be dropped.
> supply its own MAC address, but I agree with him that if this is also
> supplied by the Relay Agent, the server should prefer the Relay Agent's
> version of the MAC address.
> >
> >
> > If you go down that route, then the client doesn't need to provide it at
> all - either the server (if on the same link) or the relay agent (for
> remote clients) would be able to extract the hardware address from the
> packet - at least for ethernet like network types.
> >
> > --
> > Simon Hobson
> >

---

From: Simon Hobson <[email-masked]>
Date: Thu, 9 Feb 2012 23:28:00 +0000

Andre Kostur wrote:

>>If you go down that route, then the client doesn't need to provide 
>>it at all - either the server (if on the same link) or the relay 
>>agent (for remote clients) would be able to extract the hardware 
>>address from the packet - at least for ethernet like network types.

>What about a relay agent which doesn't know about this option?

In some respects it's the same problem as making clients do something 
new - if you want to use that option in your config then all the 
clients need to provide it, or all the relay agents and/or the server 
need to provide it. Either way, code needs to change - and in the 
general case that means multiple vendors changing stuff.

The question was raised of "do you trust the client to supply this ?" 
The answer is probably that you have to - since the client can spoof 
any MAC address anyway if it wants to do bad things. So it's probably 
not an issue.

As I see it, you can either let the client provide it as an option - 
so relay agents and servers don't need changes Or you can leave the 
client alone and let the server/relay agent determine it. It wouldn't 
make sense to have the client do it under some circumstances, and the 
relay agent under other circumstances.
There is the other issue of doing it in the relay agent - and that's 
much like the problems with Option 82 in the IPv4 world, where it's 
added by the relay agent for broadcast requests, but not to unicast 
packets sent directly from the client to the server (unless the relay 
agent is in the packet path and modifies unicast packets as well).

I'm thinking it's probably easiest to implement as a client adding it 
as another option.

-- 
Simon Hobson

---

From: Chuck Anderson <[email-masked]>
Date: Thu, 9 Feb 2012 18:34:18 -0500

On Thu, Feb 09, 2012 at 09:50:06PM +0000, Simon Hobson wrote:
>> supplied by the Relay Agent, the server should prefer the Relay  

We implemented a proof of concept of this approach using ISC dhcrelay,
although we extracted the Ethernet address from the ND table on the
Relay Agent and then put it into a Relay option.  It is quite a pain
for the server (or relay for that matter) to have to peek into L2
headers in many implementations, but I'll take that over nothing.  The
ND table approach may be a better one, but that is an implementation
detail.

---

From: Chuck Anderson <[email-masked]>
Date: Thu, 9 Feb 2012 18:36:47 -0500

> address and link-layer address).

Agree.

> might be called Client Link-Layer Address Option).

Agree.

> like PXE booting, there might be reasons to have the client provide it.

Disagree, I would like to allow a client or relay to use this because
they can be useful in different cases.

> client provided information, so I think the following is bad and

Agree.

> messages. Best to not list things that are not needed and are not

Agree.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 9 Feb 2012 19:49:09 -0500

skipping relay is not an issue - in v6 clients multicast ALL packets unless server tells them via option they can unicast.

Sent from my iPhone

On Feb 9, 2012, at 6:28 PM, "Simon Hobson" <[email-masked]> wrote:

> There is the other issue of doing it in the relay agent - and that's much like the problems with Option 82 in the IPv4 world, where it's added by the relay agent for broadcast requests, but not to unicast packets sent

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Fri, 10 Feb 2012 07:47:09 +0530

Thanks for the discussion and review guys. We will take care of these
review comments in the next revision which will be out soon.

Regards,
Gaurav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bernie Volz (volz)
Sent: Friday, February 10, 2012 6:19 AM
To: Simon Hobson
Cc: [email-masked]
Subject: Re: [dhcwg] DHCPv6 Hardware Option

skipping relay is not an issue - in v6 clients multicast ALL packets
unless server tells them via option they can unicast.

Sent from my iPhone

packets sent