Subject: [dhcwg] IETF83 dhcwg agenda items

From: "Brzozowski, John" <[email-masked]>
Date: Mon, 12 Mar 2012 18:48:52 +0000

Folks,

For those of you that have new or existing work that requires time during
the IETF83 dhcwg  meeting please send us mail with your request.

If you have already sent us your request please confirm your request,
apologies for any inconvenience.

Thank you,

John

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 12 Mar 2012 21:49:02 +0100

> apologies for any inconvenience.
I would like to ask for 2 slots for the following drafts:

1. DHCPv6 failover update: 15-30 minutes, depending on time constraints
this can be reasonably brief (just announcing that we have initial
design, layout general ideas) or rather detailed (also present state
machine with states + extra details):
draft-mrugalski-dhc-dhcpv6-failover-requirements-01
draft-mrugalski-dhc-dhcpv6-failover-design-01

2. Requesting DHCPv6 Suboptions (10 minutes)
draft-mrugalski-dhc-dhcpv6-suboptions-02

Other drafts that I'm involved in (and possibly could present, if
needed) are listed below. I don't plan to present them unless you think
that they should be presented.

3. draft-ietf-dhc-dhcpv6-redundancy-consider-02 (passed WGLC already,
there is nothing to do in WG about this, authors need to update based on
IESG feedback)

4. draft-mdt-softwire-map-dhcp-option-02 (I presented similar work
called 4rd back then in Prague and was told to not present similar stuff
before it is actually adopted by Softwires and that didn't happen yet)

5. draft-ietf-mif-dhcpv6-route-option-04 (that was presented already,
there are changes since -03, but current issues are not related to
DHCP-side of things, but rather related to routing aspects)

Cheers,
Tomek

---

From: shwethab <[email-masked]>
Date: Tue, 13 Mar 2012 09:43:46 +0530

Hi John,

Request you to allocate slots for the following 3 drafts:

Following 2 we would like to present and poll for wg adoption
1. draft-bhandari-dhc-class-based-prefix-01.txt - (10 mins) We had presented
this in Taiwan and there was considerable interest in wg. We would like to
present how this new option helps in "Prefix coloring" usecase in mobile
networks   
2. draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 (5 mins)- We have
addressed the review comments received. There was interest expressed in wg
and the mailer for this to be adopted as a wg draft.

Authors of draft-ietf-dhc-client-id-02 (5 mins) have requested me to present
the status of this draft and check for WG last call as there are no pending
review comments.

Thanks,
Shwetha

On 3/13/12 12:18 AM, "Brzozowski, John" <[email-masked]>
wrote:

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

---

From: Cui Yang <[email-masked]>
Date: Tue, 13 Mar 2012 06:38:05 +0000

Hi, John and Ted

We have just updated a draft on "Security option extensions for DHCPv4".
May I have 10 mins to present this in the coming Paris meeting?

The draft proposed to use new DHC options to assign crucial security configuration parameters,
which has important use cases, such as, secure self-booting in network.
Thanks for your consideration.

Filename:	 draft-bi-dhc-sec-option
Revision:	 01
Title:		 Security option extensions for DHCPv4
Creation date:	 2012-03-12
WG ID:		 Individual Submission
Number of pages: 9

Abstract:
   This document defines a new option that can be used by DHCP servers
   to exchange with DHCP clients specific security configuration
   information.  This new option defines a standard parameter format and
   code so that there will be no ambiguity in interoperating the
   information being exchanged and that there will be no issues related
   to interoperability.  It is an option definition extension for DHCPv4
   which should be included in RFC 2132.

Best regards,
Yang
==================
 Yang Cui,  Ph.D.
 Huawei Technologies
 [email-masked]

> -----邮件原件-----
> 发件人: Brzozowski, John [mailto:[email-masked]]
> 发送时间: 2012年3月13日 2:49
> 收件人: dhc WG
> 主题: [dhcwg] IETF83 dhcwg agenda items
> 
> Folks,
>

---

From: Leaf yeh <[email-masked]>
Date: Tue, 13 Mar 2012 11:08:36 +0000

Hi, Chairs

I'd like to present my new draft "Authorization Option for DHCPv6 Relay Agents on Broadband Access Server" in the DHC session of IETF83 within 10 mins.

Best Regards,
Leaf

PS. https://datatracker.ietf.org/doc/draft-yeh-dhc-dhcpv6-authorization-opt/?include_text=1 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brzozowski, John
Sent: Tuesday, March 13, 2012 2:49 AM
To: dhc WG
Subject: [dhcwg] IETF83 dhcwg agenda items

Folks,

Thank you,

John

---

From: perl-list <[email-masked]>
Date: Tue, 13 Mar 2012 09:05:37 -0400 (EDT)

I am quite interested in this draft: draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 proposed by the Cisco engineers. Do you know if there will be an opportunity to view (or listen to) this meeting online somehow for those of us who cannot make it to Paris? 

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

> From: "John Brzozowski" <[email-masked]>
> To: "dhc WG" <[email-masked]>
> Sent: Monday, March 12, 2012 2:48:52 PM

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Mar 2012 13:59:30 +0000

On Mar 13, 2012, at 9:05 AM, perl-list <[email-masked]<mailto:[email-masked]>> wrote:
I am quite interested in this draft: draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 proposed by the Cisco engineers.  Do you know if there will be an opportunity to view (or listen to) this meeting online somehow for those of us who cannot make it to Paris?

If you go to the online agenda you will find links for the audio session, and for the jabber room as well.

---

From: Ole Trøan <[email-masked]>
Date: Tue, 13 Mar 2012 09:22:11 -0700

Chairs,

> apologies for any inconvenience.

I'd like to ask for a slot to discuss:
 - the RFC3315/RFC3633 errata required by RFC6204/RFC6204bis
 - changes required to the DHC protocol to handle multiple stateful options in a single session

there is currently not a published draft describing all the issues, but I've compiled a list from the mailing list discussions that will be published ASAP. in addition I'm hoping we can get some people together before the WG slot, so that we can report results at the Thursday meeting.

20 minutes?

cheers,
Ole

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 13 Mar 2012 12:36:27 -0500

I support Ole's request.

Thanks and regards,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Trøan
Sent: Tuesday, March 13, 2012 12:22 PM
To: Brzozowski, John
Cc: dhc WG
Subject: Re: [dhcwg] IETF83 dhcwg agenda items

Chairs,

20 minutes?

cheers,
Ole

---

From: Peng Wu <[email-masked]>
Date: Wed, 14 Mar 2012 10:47:00 +0800

Hi John,

We'd like to request 10 min to present the update on the DHCPv4 over
IPv6 Transport draft
http://tools.ietf.org/id/draft-ietf-dhc-dhcpv4-over-ipv6-01.txt

Thanks.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 15 Mar 2012 09:09:54 -0500

Woj,

It would be good to provide context and more descriptive use cases for
the draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01.  Specifically which
set of SP's or any other standards body outside of the IETF have asked
for such work?  With additional data, we all can see what else can be
done.  At the last IETF, JohnB (co-Chair) suggested to use a
vendor-specific option and I agree with him.  IPv6 is already deployed
in cable broadband for dual-stack IP services just fine with the Cisco
CNR (DHCPv6 server) and backend provisioning systems in the BACC. Such a
deployment already knows how to associate a dual-stack client.  

A few others who have responded to move the
draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 forward in the DHC WG
should also articulate what their use case is and what is the
showstopper problem they have that the IETF should look into this work.

Thanks,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Shwetha Bhandari (shwethab)
Sent: Tuesday, March 13, 2012 12:14 AM
To: Brzozowski, John; dhc WG
Cc: Sri Gundavelli (sgundave)
Subject: Re: [dhcwg] IETF83 dhcwg agenda items

Hi John,

Following 2 we would like to present and poll for wg adoption
1. draft-bhandari-dhc-class-based-prefix-01.txt - (10 mins) We had
presented
this in Taiwan and there was considerable interest in wg. We would like
to
present how this new option helps in "Prefix coloring" usecase in mobile
networks   
2. draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 (5 mins)- We have
addressed the review comments received. There was interest expressed in
wg
and the mailer for this to be adopted as a wg draft.

Authors of draft-ietf-dhc-client-id-02 (5 mins) have requested me to
present
the status of this draft and check for WG last call as there are no
pending
review comments.

Thanks,
Shwetha

On 3/13/12 12:18 AM, "Brzozowski, John"
<[email-masked]>

---

From: perl-list <[email-masked]>
Date: Thu, 15 Mar 2012 12:11:04 -0400 (EDT)

Hemant, 

This summary, after a 160+ post thread from the isc mail group dhcp-users, should sum up the need for a hardware option quite nicely: 

DHCPv6 host-identifier, the Never Ending Thread: A Summary 
https://lists.isc.org/pipermail/dhcp-users/2009-March/008678.html 

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

> From: "Hemant Singh (shemant)" <[email-masked]>
> To: "Shwetha Bhandari (shwethab)" <[email-masked]>, "John
> Brzozowski" <[email-masked]>, "dhc WG"
> <[email-masked]>
> Cc: "Wojciech Dec (wdec)" <[email-masked]>
> Sent: Thursday, March 15, 2012 10:09:54 AM

---

From: perl-list <[email-masked]>
Date: Thu, 15 Mar 2012 12:19:44 -0400 (EDT)

In case you are curious about the original 160+ message thread, here is a link to it: 

host-identifier with IPv6 
https://lists.isc.org/pipermail/dhcp-users/2009-March/008489.html 

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

> From: "perl-list" <[email-masked]>
> To: "Hemant Singh (shemant)" <[email-masked]>
> Cc: "dhc WG" <[email-masked]>, "Wojciech Dec (wdec)" <[email-masked]>
> Sent: Thursday, March 15, 2012 12:11:04 PM

> This summary, after a 160+ post thread from the isc mail group
> dhcp-users, should sum up the need for a hardware option quite
> nicely:

> > addressed the review comments received. There was interest
> > expressed
> > in
> 
> > wg
> 

> > > Folks,
> 
> > >
> 
> > > For those of you that have new or existing work that requires
> > > time
> 
> > during
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 15 Mar 2012 12:22:39 -0500

Thanks much for the URL to the details.   Woj’s documents mentions a slightly different problem which is how does an SP find dual-stack DHCPv4 and DHCPv6 clients.   To that problem, I already pointed to products and cable deployment that already knows how to ID clients that are dual-stack in the SP network.    The new links sent to me are more of a Enterprise deployment.   

I prefer cleaner solutions but my thought will not be liked by DHCPv6 server vendors nor relay vendors.   Forget adding a new hardware option to DHCPv6.  DHCPv6 made a fundamental mistake excluding the hardware address from the protocol.   So ack that mistake, remove the DUID from the protocol, and replace the DUID with the chaddr of DHCPv4.   Most hosts implemented a changing DUID (DUID-LLT) on each client reset and the server allocated a new PD to each client!  Not to mention how does an admin of the DHCPv6 server identify DHCPv6 clients if the DUID changed on each client reset?    For the IPv6 CE router RFC 6204, because the document limits itself to one device in the IPv6 CE router, we could  tighten the language to force the device to keep the DUID persistent.   See bullet W-6 in http://tools.ietf.org/html/rfc6204

Regards,

Hemant

From: perl-list [mailto:[email-masked]] 
Sent: Thursday, March 15, 2012 12:20 PM
To: Hemant Singh (shemant)
Cc: dhc WG; Wojciech Dec (wdec)
Subject: Re: [dhcwg] IETF83 dhcwg agenda items

________________________________

	Hemant,

	
________________________________

		To: "Shwetha Bhandari (shwethab)" <[email-masked]>, "John Brzozowski" <[email-masked]>, "dhc WG" <[email-masked]>
		
		Woj,

		Thanks,
		
		Hemant
		
		-----Original Message-----
		From: [email-masked] [mailto:[email-masked]] On Behalf
		Of Shwetha Bhandari (shwethab)
		Sent: Tuesday, March 13, 2012 12:14 AM
		To: Brzozowski, John; dhc WG
		Cc: Sri Gundavelli (sgundave)
		Subject: Re: [dhcwg] IETF83 dhcwg agenda items
		
		Hi John,

		
		
		Thanks,
		Shwetha

---

From: Andre Kostur <[email-masked]>
Date: Thu, 15 Mar 2012 11:05:58 -0700

If the DUID-LLT is changing on each reset, then the client is broken.  The
DHCP spec already makes the DUID persistent.  RFC 3315, section 9.2:

   Clients and servers using this type of DUID MUST store the DUID-LLT
   in stable storage, and MUST continue to use this DUID-LLT even if the
   network interface used to generate the DUID-LLT is removed.  Clients
   and servers that do not have any stable storage MUST NOT use this
   type of DUID.

On Thu, Mar 15, 2012 at 10:22, Hemant Singh (shemant) <[email-masked]>wrote:

> Thanks much for the URL to the details.   Woj’s documents mentions a
> slightly different problem which is how does an SP find dual-stack DHCPv4
> and DHCPv6 clients.   To that problem, I already pointed to products and
> cable deployment that already knows how to ID clients that are dual-stack
> in the SP network.    The new links sent to me are more of a Enterprise
> deployment.   ****
>
> ** **
>
> I prefer cleaner solutions but my thought will not be liked by DHCPv6
> server vendors nor relay vendors.   Forget adding a new hardware option to
> DHCPv6.  DHCPv6 made a fundamental mistake excluding the hardware address
> from the protocol.   So ack that mistake, remove the DUID from the
> protocol, and replace the DUID with the chaddr of DHCPv4.   Most hosts
> implemented a changing DUID (DUID-LLT) on each client reset and the server
> allocated a new PD to each client!  Not to mention how does an admin of the
> DHCPv6 server identify DHCPv6 clients if the DUID changed on each client
> reset?    For the IPv6 CE router RFC 6204, because the document limits
> itself to one device in the IPv6 CE router, we could  tighten the language
> to force the device to keep the DUID persistent.   See bullet W-6 in
> http://tools.ietf.org/html/rfc6204****
>
> ** **
>
> Regards,****
>
> ** **
>
> Hemant****
>
> ** **
>
> *From:* perl-list [mailto:[email-masked]]
> *Sent:* Thursday, March 15, 2012 12:20 PM
> *To:* Hemant Singh (shemant)
> *Cc:* dhc WG; Wojciech Dec (wdec)
>
> *Subject:* Re: [dhcwg] IETF83 dhcwg agenda items****
>
> ** **
>
> In case you are curious about the original 160+ message thread, here is a
> link to it:****
>
> ** **
>
> *host-identifier with IPv6*****
>
> https://lists.isc.org/pipermail/dhcp-users/2009-March/008489.html****
>
> ** **
> ------------------------------
>
> *From: *"perl-list" <[email-masked]>
> *To: *"Hemant Singh (shemant)" <[email-masked]>
> *Cc: *"dhc WG" <[email-masked]>, "Wojciech Dec (wdec)" <[email-masked]>
> *Sent: *Thursday, March 15, 2012 12:11:04 PM
> *Subject: *Re: [dhcwg] IETF83 dhcwg agenda items****
>
> Hemant,****
>
> ** **
>
> This summary, after a 160+ post thread from the isc mail group dhcp-users,
> should sum up the need for a hardware option quite nicely:****
>
> ** **
>
> *DHCPv6 host-identifier, the Never Ending Thread: A Summary*****
>
> https://lists.isc.org/pipermail/dhcp-users/2009-March/008678.html****
>
> ** **
> ------------------------------
>
> *From: *"Hemant Singh (shemant)" <[email-masked]>
> *To: *"Shwetha Bhandari (shwethab)" <[email-masked]>, "John
> Brzozowski" <[email-masked]>, "dhc WG" <[email-masked]>
> *Cc: *"Wojciech Dec (wdec)" <[email-masked]>
> *Sent: *Thursday, March 15, 2012 10:09:54 AM
> *Subject: *Re: [dhcwg] IETF83 dhcwg agenda items
>
> Woj,
>
> https://www.ietf.org/mailman/listinfo/dhcwg****
>
> ** **
>
>
> https://www.ietf.org/mailman/listinfo/dhcwg****
>
> ** **
>

-- 
 *Andre Kostur*

---

From: perl-list <[email-masked]>
Date: Thu, 15 Mar 2012 14:23:49 -0400 (EDT)

I fully support adding the hardware address to the DHCP messages however that happens. If it means replacing the DUID that is very much fine with me. In whatever shape or form the hardware address makes it in the packet, I would be very happy to see it there as it would make implementation of parity between DHCPv4 and DHCPv6 clients MUCH simpler as we move into the dual-stack period of the Internet. Currently it is very nearly impossible to have parity without some special vendor equipment of some kind, as far as I can tell (ISC DHCP 4.2.3) on a consistent basis. Not all clients use the hardware address to generate the DUID per RFC. Without the hardware address there, telling which DHCPv4 client matches which DHCPv6 client is not possible. 

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

> To: "perl-list" <[email-masked]>
> Sent: Thursday, March 15, 2012 1:22:39 PM
> Subject: RE: [dhcwg] IETF83 dhcwg agenda items

> slightly different problem which is how does an SP find dual-stack
> DHCPv4 and DHCPv6 clients. To that problem, I already pointed to
> products and cable deployment that already knows how to ID clients
> that are dual-stack in the SP network. The new links sent to me are
> more of a Enterprise deployment.

> server vendors nor relay vendors. Forget adding a new hardware
> option to DHCPv6. DHCPv6 made a fundamental mistake excluding the
> hardware address from the protocol. So ack that mistake, remove the
> DUID from the protocol, and replace the DUID with the chaddr of
> DHCPv4. Most hosts implemented a changing DUID (DUID-LLT) on each
> client reset and the server allocated a new PD to each client! Not
> to mention how does an admin of the DHCPv6 server identify DHCPv6
> clients if the DUID changed on each client reset? For the IPv6 CE
> router RFC 6204, because the document limits itself to one device in
> the IPv6 CE router, we could tighten the language to force the
> device to keep the DUID persistent. See bullet W-6 in
> http://tools.ietf.org/html/rfc6204

> > > It would be good to provide context and more descriptive use
> > > cases
> > > for
> > 
> 

> > > this in Taiwan and there was considerable interest in wg. We
> > > would
> > > like
> > 
> 
> > > to
> > 
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 15 Mar 2012 14:00:23 -0500

Please note that one reason I have heard why the DUID was introduced in DHCPv6 is also included in the following text for RFC 3315.

[a device's DUID should not change as a result of a change in

the device's network hardware.]

How much to admins of networks and DHCPv6 server care about changed NIC card in a PC that is also a DHCPv6 client?  Why not just call one's admin to report a changed NIC card.  Laptops now have built-in wireless and there is no Ethernet hardware changing on such machines.  If folks are willing to give up the “changed NIC card” requirement, one could dispense with the DUID.   I prefer one identifier to identify a client in either of hardware address or DUID but not both.  Thus if folks want a hardware address, then one could consider deprecating the DUID.

My intent is to not rock the boat because SPs are planning on DHCPv6 deployments as we speak.  However, if the protocol is changing for hardware address inclusion why not make a clean change rather than a band-aid that has a DHCPv6 protocol that supports both DUID and hardware address.

Hemant 

Sent: Thursday, March 15, 2012 2:24 PM

________________________________________

 

Regards,

Hemant

________________________________________

Hemant,

________________________________________

Woj,

 

Thanks,

Hemant

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

Hi John,

presented

to

networks   

wg

present

pending

review comments.

Thanks,

Shwetha

> For those of you that have new or existing work that requires time

during

dhcwg mailing list

[email-masked]

dhcwg mailing list

[email-masked]

 

dhcwg mailing list

[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Mar 2012 19:20:34 +0000

On Mar 15, 2012, at 12:19 PM, perl-list <[email-masked]<mailto:[email-masked]>> wrote:
In case you are curious about the original 160+ message thread, here is a link to it:

It's probably worth noting that Cisco has, unfortunately, patented the original and ingenious technique whereby the relay agent captures the layer 2 source address from which it receives a client message, and records it in the relay agent options portion of the relayed message.

This argues, as you say, for having the client include the information, since I don't think Cisco has patented that.  I personally prefer Cisco's ingenious and patented solution, but it's probably best not to use it, so as to avoid future patent trolling.

(In case any IP lawyers troll this message later, I'd like to be clear that I am being sarcastic when I call this technique ingenious.   Were I speaking literally rather than sarcastically, I would describe it as blazingly obvious to any practitioner in the field.)

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Mar 2012 19:23:35 +0000

On Mar 15, 2012, at 1:22 PM, Hemant Singh (shemant) <[email-masked]<mailto:[email-masked]>> wrote:
Most hosts implemented a changing DUID (DUID-LLT) on each client reset and the server allocated a new PD to each client!

Such hosts do not have DHCPv6 clients: the spec expressly forbids this behavior.   They have something that implements a DHCPv6-like configuration protocol, but it is not DHCPv6.

The hardware address is an extremely poor choice for client identifier.   Do we really need to have yet another interminable debate about this?

---

From: perl-list <[email-masked]>
Date: Thu, 15 Mar 2012 15:27:43 -0400 (EDT)

Oh boy - yes a patented solution would not work very well unless it can be guaranteed that one will ONLY run into Cisco gear in the field (which it most assuredly cannot). 

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

> From: "Ted Lemon" <[email-masked]>
> Cc: "Hemant Singh (shemant)" <[email-masked]>, "dhc WG"
> <[email-masked]>, "Wojciech Dec (wdec)" <[email-masked]>
> Sent: Thursday, March 15, 2012 3:20:34 PM

> On Mar 15, 2012, at 12:19 PM, perl-list < [email-masked] >
> wrote:
> > In case you are curious about the original 160+ message thread,
> > here
> > is a link to it:
> 

> It's probably worth noting that Cisco has, unfortunately, patented
> the original and ingenious technique whereby the relay agent
> captures the layer 2 source address from which it receives a client
> message, and records it in the relay agent options portion of the
> relayed message.

> This argues, as you say, for having the client include the
> information, since I don't think Cisco has patented that. I
> personally prefer Cisco's ingenious and patented solution, but it's
> probably best not to use it, so as to avoid future patent trolling.

> (In case any IP lawyers troll this message later, I'd like to be
> clear that I am being sarcastic when I call this technique
> ingenious. Were I speaking literally rather than sarcastically, I
> would describe it as blazingly obvious to any practitioner in the
> field.)

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Mar 2012 19:31:08 +0000

On Mar 15, 2012, at 3:27 PM, perl-list <[email-masked]<mailto:[email-masked]>> wrote:
Oh boy - yes a patented solution would not work very well unless it can be guaranteed that one will ONLY run into Cisco gear in the field (which it most assuredly cannot).

Cisco's offered the patent under FRAND terms, but you never know what might happen going forward.

---

From: Chuck Anderson <[email-masked]>
Date: Thu, 15 Mar 2012 15:41:47 -0400

> message, and records it in the relay agent options portion of the

Which patent is it?  There may be documented prior art here.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 15 Mar 2012 14:47:03 -0500

https://datatracker.ietf.org/ipr/1710/

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Chuck Anderson
Sent: Thursday, March 15, 2012 3:42 PM
To: Ted Lemon
Cc: dhc WG; Wojciech Dec (wdec)
Subject: Re: [dhcwg] IETF83 dhcwg agenda items

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Mar 2012 19:47:20 +0000

On Mar 15, 2012, at 3:41 PM, Chuck Anderson <[email-masked]<mailto:[email-masked]>>
 wrote:
Which patent is it?  There may be documented prior art here.

Dunno.   Doesn't matter.   If we have two techniques that will both work, and one is patented, and the other is not, then we're just saving ourselves future pain if we avoid the one that's patented.   Patent litigation is a waste of time and money, and very much worth avoiding even if the patent being litigated has obvious prior art.

(Of course, it's always possible that there's a submarine patent on including the MAC address in a DHCPv6 client packet... :)

---

From: [email-masked]
Date: Thu, 15 Mar 2012 20:47:43 +0100 (CET)

> The hardware address is an extremely poor choice for client identifier.   Do we really need to have yet another interminable debate about this?

As long as we can have the MAC address in some way, it doesn't have to
be *the* client identifier.

Having said that - I still haven't seen many positive comments about
the various DUID forms from system / network administrators. I *have*
seen lots of negative comments about not including the MAC address.

In the IPv4 world my most frequent requirement is to *only* use the
MAC address (and completely ignore the client identifier). I expect
the same will be the case in the IPv6 world.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Mar 2012 19:55:19 +0000

On Mar 15, 2012, at 3:47 PM, <[email-masked]<mailto:[email-masked]>>
 <[email-masked]<mailto:[email-masked]>> wrote:
Having said that - I still haven't seen many positive comments about
the various DUID forms from system / network administrators. I *have*
seen lots of negative comments about not including the MAC address.

The DUID wasn't created with administrators in mind.   It's an opaque, unique cookie used by the protocol.   As well say that system administrators don't like the format of the shared keys in SSL.

---

From: perl-list <[email-masked]>
Date: Thu, 15 Mar 2012 15:59:09 -0400 (EDT)

I hope this isn't going to descend into an argument about DUID vs hardware address. Client ID and chaddr managed to successfully co-exist in DHCPv4 ... perchance they can in DHCPv6 as well? 

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

> To: "<[email-masked]> <[email-masked]>" <[email-masked]>
> Cc: "<[email-masked]>" <[email-masked]>, "<[email-masked]>"
> <[email-masked]>
> Sent: Thursday, March 15, 2012 3:55:19 PM

> On Mar 15, 2012, at 3:47 PM, < [email-masked] >
> < [email-masked] > wrote:
> The DUID wasn't created with administrators in mind. It's an opaque,
> unique cookie used by the protocol. As well say that system
> administrators don't like the format of the shared keys in SSL.

---

From: [email-masked]
Date: Thu, 15 Mar 2012 21:02:09 +0100 (CET)

> I hope this isn't going to descend into an argument about DUID vs hardware address. Client ID and chaddr managed to successfully co-exist in DHCPv4 ... perchance they can in DHCPv6 as well? 

As long as administrators can have the MAC address, I'm sure they can.

---

From: perl-list <[email-masked]>
Date: Thu, 15 Mar 2012 16:06:59 -0400 (EDT)

I also support that statement. 

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

> From: [email-masked]
> To: [email-masked]
> Cc: "Ted Lemon" <[email-masked]>, [email-masked],
> [email-masked]
> Sent: Thursday, March 15, 2012 4:02:09 PM

> > I hope this isn't going to descend into an argument about DUID vs
> > hardware address. Client ID and chaddr managed to successfully
> > co-exist in DHCPv4 ... perchance they can in DHCPv6 as well?

> As long as administrators can have the MAC address, I'm sure they

I also support that statement.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Mar 2012 20:09:54 +0000

On Mar 15, 2012, at 3:59 PM, perl-list <[email-masked]<mailto:[email-masked]>> wrote:
I hope this isn't going to descend into an argument about DUID vs hardware address. Client ID and chaddr managed to successfully co-exist in DHCPv4 ... perchance they can in DHCPv6 as well?

Exactly right.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 15 Mar 2012 18:55:29 -0400

On Mar 15, 2012, at 3:31 PM 3/15/12, Ted Lemon wrote:

> On Mar 15, 2012, at 3:27 PM, perl-list <[email-masked]> wrote:

Just to be clear, and recognizing my affiliation with Cisco, the IPR disclosure includes the same licensing terms that have been found acceptable in other situations (and, of course, have been found unacceptable in some situations, as well).

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Mar 2012 00:51:20 +0000

On Mar 15, 2012, at 6:55 PM, Ralph Droms <[email-masked]<mailto:[email-masked]>>
 wrote:
Just to be clear, and recognizing my affiliation with Cisco, the IPR disclosure includes the same licensing terms that have been found acceptable in other situations (and, of course, have been found unacceptable in some situations, as well).

Yup, nothing against Cisco.   It's not a big deal, but it does make a difference.   DHCP is fairly unencumbered by patents, with a few notable exceptions like Motorola's patent on the Relay Agent Information option.   If we have a choice I'd argue that we should choose the unencumbered solution, but if the WG consensus turns out to be that the relay agent solution is better, that's what we'll do.

---

From: Chuck Anderson <[email-masked]>
Date: Thu, 15 Mar 2012 21:27:35 -0400

> Yup, nothing against Cisco.   It's not a big deal, but it does make a difference.   DHCP is fairly unencumbered by patents, with a few notable exceptions like Motorola's patent on the Relay Agent I…

I like the relay agent solution better, because it is easier for me to
deploy a few relay agents with a new feature than to wait until my
client base upgrades to a sufficient extent that I can write off old
clients (e.g. not support/service them with DHCP, which might perhaps
never happen).

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 15 Mar 2012 20:31:51 -0500

From: [email-masked] [mailto:[email-masked]] On Behalf Of perl-list
Sent: Thursday, March 15, 2012 3:59 PM
To: Ted Lemon
Cc: dhcwg; Wojciech Dec (wdec)
Subject: Re: [dhcwg] IETF83 dhcwg agenda items

>I hope this isn't going to descend into an argument about DUID vs hardware address. Client ID and chaddr managed to successfully co-exist in DHCPv4 ... perchance they can in DHCPv6 as well?

Thanks for this reminder.  In that case, certainly I agree too that client id and chaddr can coexist in DHCPv6.  I just have one last nit-pick.  Six bytes of more data on the wire and that many more bytes per client to store on the DHCPv6 server. Sorry, my natural tendency is to use least bits everywhere since I work on embedded systems.

Regards,

Hemant

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Mar 2012 01:55:58 +0000

On Mar 15, 2012, at 9:31 PM, "Hemant Singh (shemant)" <[email-masked]<mailto:[email-masked]>>
 wrote:
Thanks for this reminder.  In that case, certainly I agree too that client id and chaddr can coexist in DHCPv6.  I just have one last nit-pick.  Six bytes of more data on the wire and that many more bytes per client to store on the DHCPv6 server. Sorry, my natural tendency is to use least bits everywhere since I work on embedded systems.

This also argues for the relay agent solution, because then we can turn off MAC addresses for the vast majority of cases where they are not needed.   E.g., my ISP does not need to know my MAC address, and on a typical home gateway, if any of them ever support DHCPv6, the MAC address will be superfluous.

Like Chuck, I prefer this solution.   I wish you guys hadn't patented it.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 15 Mar 2012 21:52:31 -0500

Ted:

If there's a few minutes left on the agenda, I want to get a quick sense
of if there is interest in the (now expired) Active DHCPv4 Lease Query
draft (draft-kinnear-dhc-dhcpv6-active-leasequery-01). As hopefully the
DHCPv4 Bulk Leasequery draft will move forward soon, be useful to see
how much interest there is in active leasequery. We have implemented
this (using something close to the draft) and have customers using it.
So, there is some real demand. But the question is whether there is
interest to standardize this by the DHC WG. Kim won't be at the IETF
this time (hopefully next one), but I will be. While we need to take
this to the list, asking at a WG meeting is a good indication.

-          Bernie

---

From: perl-list <[email-masked]>
Date: Fri, 16 Mar 2012 09:01:32 -0400 (EDT)

> clients (e.g. not support/service them with DHCP, which might perhaps

I also like the relay agent solution for that reason. Right now, however, we have a small handful of DHCPv6 clients available. Linux (ISC DHCP and Dibbler) ; D-Link ; MacOS ; Windows7+ ; Various commercial network equipment manufacturers such as Cisco and Juniper. Before the low end home router market enters the fray might be the time to change the client base...

---

From: perl-list <[email-masked]>
Date: Fri, 16 Mar 2012 09:58:34 -0400 (EDT)

Reading the IPR disclosure... I see what Cisco is doing here. Having a few well placed patents to protect itself against patent trolls: 

" Cisco retains the right to assert its patents (including the right 
to claim past royalties) against any party that asserts a patent it owns or controls (either 
directly or indirectly) against Cisco" 

That actually makes good sense to me. Mutually assured destruction. 

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

> From: "Wojciech Dec" <[email-masked]>
> To: "Ted Lemon" <[email-masked]>, "perl-list"
> <[email-masked]>
> <[email-masked]>, "Ralph Droms" <[email-masked]>
> Sent: Friday, March 16, 2012 4:38:01 AM

> Re: [dhcwg] IETF83 dhcwg agenda items The IPR disclosure re
> draft-halwasia is under:

> You’ll note that the license terms are free right to use under
> reasonable, non-discriminatory terms, etc.
> It’s perhaps also useful to note that IPR disclosures, and from
> seemingly various sources apply to numerous DHCP drafts, including
> RFC2131, and other standard RFCs. Where is the recommendation from
> the chair(s) or the IETF not to use these RFCs or specific parts of
> them, or not to consider drafts with disclosed IPR?
> In terms of patent trolls, they’re likely not to be disclosing and we
> can only speculate as to what obvious or not obvious IPRs they have
> or don’t have, and the like. Or we can go back to being a technical
> community, and leave such matters to subject matter experts, which
> personally would be my preference.

> -Woj.

> On 15/03/2012 20:20, "Ted Lemon" < [email-masked] > wrote:

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Mar 2012 14:00:33 +0000

On Mar 16, 2012, at 4:38 AM, Wojciech Dec <[email-masked]<mailto:[email-masked]>> wrote:
It’s perhaps also useful to note that IPR disclosures, and from seemingly various sources apply to numerous DHCP drafts, including RFC2131, and other standard RFCs.  Where is the recommendation from the chair(s) or the IETF not to use these RFCs or specific parts of them, or not to consider drafts with disclosed IPR?

Any patent relating to RFC2131 would necessarily have expired by now.

In terms of patent trolls, they’re likely not to be disclosing and we can only speculate as to what obvious or not obvious IPRs  they have or don’t have, and the like. Or we can go back to being a technical community, and leave such matters to subject matter experts, which personally would be my preference.

Cisco isn't a patent troll.   But neither was Yahoo, ten years ago.   I'm sorry if it feels like I was suggesting otherwise; what I'm saying is simply that given two solutions, both of which work, the one that's not patented is preferable, regardless of licensing terms.

There are actually some good technical reasons for choosing the relay-agent-based solution, so it's not really an apples-to-apples comparison.

My disappointment with Cisco in this case is simply that the patented technique is dead obvious and is based on a technique documented (and also unfortunately patented!) by Motorola in RFC3046.   So we have to make an unpleasant decision about this technique merely because someone at Cisco didn't say "no" to the lawyers, and if we choose to go with the preferable technique, we are putting future implementors at risk of litigation (the FRAND terms protect present implementors, but it's not clear that they can't be withdrawn, and certainly no assurance is given that they will not be withdrawn).

Anyway, I suspect most of the people reading this are bored with this discussion, and I apologize for continuing it, but you seemed surprised by my position on the topic, so I just wanted to be clear about what I was saying.   I've changed the subject line so that people who don't want to hear any more about this can mute it.

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 16 Mar 2012 09:38:01 +0100

The IPR disclosure re draft-halwasia is under:
https://datatracker.ietf.org/ipr/1710/

You¹ll note that the license terms are free right to use under reasonable,
non-discriminatory terms, etc.
It¹s perhaps also useful to note that IPR disclosures, and from seemingly
various sources apply to numerous DHCP drafts, including RFC2131, and other
standard RFCs.  Where is the recommendation from the chair(s) or the IETF
not to use these RFCs or specific parts of them, or not to consider drafts
with disclosed IPR?
In terms of patent trolls, they¹re likely not to be disclosing and we can
only speculate as to what obvious or not obvious IPRs  they have or don¹t
have, and the like. Or we can go back to being a technical community, and
leave such matters to subject matter experts, which personally would be my
preference.

-Woj.

On 15/03/2012 20:20, "Ted Lemon" <[email-masked]> wrote:

> On Mar 15, 2012, at 12:19 PM, perl-list <[email-masked]> wrote:
>> link to it: 
> It's probably worth noting that Cisco has, unfortunately, patented the
> original and ingenious technique whereby the relay agent captures the layer 2
> source address from which it receives a client message, and records it in the
> relay agent options portion of the relayed message.
> 
> This argues, as you say, for having the client include the information, since
> I don't think Cisco has patented that.  I personally prefer Cisco's ingenious
> and patented solution, but it's probably best not to use it, so as to avoid
> future patent trolling.
> 
> (In case any IP lawyers troll this message later, I'd like to be clear that I
> am being sarcastic when I call this technique ingenious.   Were I speaking
> literally rather than sarcastically, I would describe it as blazingly obvious
> to any practitioner in the field.)
> 
>

---

From: Simon Hobson <[email-masked]>
Date: Fri, 16 Mar 2012 14:39:11 +0000

Ted Lemon wrote:

>The hardware address is an extremely poor choice for client 
>identifier.   Do we really need to have yet another interminable 
>debate about this?

Probably not. I thought a consensus was reached in "that thread" that :

a) the hardware address of the client isn't a good choice,

but b) we don't have anything better,

c) the hardware address is very often printed on the outside of the 
box and so can be determined without powering up the equipment,

d) most of the DUID options defined do not give an identifier that 
can be determined prior to the device being powered up and allowed to 
generate it

e) in many environments, changing/re-installing OS is at least as 
common (if not more so) as changing hardware. And multi-OS boot 
options also introduce changes in DUID

and f) many people have workflow requirements which require a known 
and defined identifier.

On that basis, the hardware address is the least bad choice that 
generally meets most admins' requirements (some permutation of c-f) - 
while in the general case, only one (the least likely to be found) of 
the DUID options do not.

Also, I think we reached a consensus that in the general case, there 
is no way to match IPv4 clients with IPv6 clients. It may be in some 
cases (eg by matching port IDs from relay agents), but in the general 
case IPv6 clients will be using DUIDs which we are specifically 
barred from looking into even if they did contain the same hardware 
address as is currently used for the interface.

If there was some standard that said all network devices had to have 
a globally unique identifier, stored immutably in hardware, and 
determinable in advance (eg scanning a barcode on the box) then we'd 
not be having these discussions. But that's not going to happen, so 
we are stuck with making the best of what we do have.

-- 
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: Fri, 16 Mar 2012 07:51:18 -0700

The prohibition of looking into the DUID may be one of the issues.  A
DUID-LLT doesn't give you any reliable info, and a DUID-EN gives you almost
nothing (although I suppose vendors could print the EN part on the box,
making it a useful identifier for the aforementioned workflow).  However,
the DUID-LL is defined as having a current network link address.  One could
use that in place of a MAC address in certain known areas (cable modems,
for example.  Use the HFC MAC address to compose the DUID-LL).

We've got RFC 6355 (DUID-UUID) and RFC 4361 (DUID in DHCPv4 client
identifiers), when taken together would be able to do most of the things
that are mentioned.

On Fri, Mar 16, 2012 at 07:39, Simon Hobson <[email-masked]> wrote:

> Ted Lemon wrote:
>
>  The hardware address is an extremely poor choice for client identifier.
>> Do we really need to have yet another interminable debate about this?
>>
>
> c) the hardware address is very often printed on the outside of the box
> and so can be determined without powering up the equipment,
>
> d) most of the DUID options defined do not give an identifier that can be
> determined prior to the device being powered up and allowed to generate it
>
> e) in many environments, changing/re-installing OS is at least as common
> (if not more so) as changing hardware. And multi-OS boot options also
> introduce changes in DUID
>
> and f) many people have workflow requirements which require a known and
> defined identifier.
>
> On that basis, the hardware address is the least bad choice that generally
> meets most admins' requirements (some permutation of c-f) - while in the
> general case, only one (the least likely to be found) of the DUID options
> do not.
>
>
> Also, I think we reached a consensus that in the general case, there is no
> way to match IPv4 clients with IPv6 clients. It may be in some cases (eg by
> matching port IDs from relay agents), but in the general case IPv6 clients
> will be using DUIDs which we are specifically barred from looking into even
> if they did contain the same hardware address as is currently used for the
> interface.
>
>
> If there was some standard that said all network devices had to have a
> globally unique identifier, stored immutably in hardware, and determinable
> in advance (eg scanning a barcode on the box) then we'd not be having these
> discussions. But that's not going to happen, so we are stuck with making
> the best of what we do have.
>
> --
> Simon Hobson
>
> Visit http://www.**magpiesnestpublishing.co.uk/<http://www.magpiesnestpublishing.co.uk/>for books by acclaimed
> ______________________________**_________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/dhcwg<https://www.ietf.org/mailman/listinfo/dhcwg>
>

-- 
 *Andre Kostur*
*
*

---

From: Simon Hobson <[email-masked]>
Date: Fri, 16 Mar 2012 14:55:29 +0000

I wrote:

>generally meets most admins' requirements (some permutation of c-f) 
>- while in the general case, only one (the least likely to be found) 
>of the DUID options do not.

Oops, typo there. It should say :
>while in the general case, only one (the least likely to be found) 
>of the DUID options does

-- 
Simon Hobson

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Mar 2012 15:43:13 +0000

On Mar 16, 2012, at 10:51 AM, Andre Kostur <[email-masked]<mailto:[email-masked]>> wrote:
The prohibition of looking into the DUID may be one of the issues.  A DUID-LLT doesn't give you any reliable info, and a DUID-EN gives you almost nothing (although I suppose vendors could print the EN part on the box, making it a useful identifier for the aforementioned workflow).  However, the DUID-LL is defined as having a current network link address.  One could use that in place of a MAC address in certain known areas (cable modems, for example.  Use the HFC MAC address to compose the DUID-LL).

That prohibition was against treating the parts of the DUID separately for the purpose of identifying the client.   It was never intended that you couldn't look at it, just that you couldn't extract the MAC address and use it as a client identifier by itself.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Mar 2012 15:47:17 +0000

On Mar 16, 2012, at 10:39 AM, Simon Hobson <[email-masked]<mailto:[email-masked]>> wrote:
Also, I think we reached a consensus that in the general case, there is no way to match IPv4 clients with IPv6 clients. It may be in some cases (eg by matching port IDs from relay agents), but in the general case IPv6 clients will be using DUIDs which we are specifically barred from looking into even if they did contain the same hardware address as is currently used for the interface.

This was not a working group discussion; what consensus may have been reached on the ISC DHCP mailing list is not a matter of interest to the working group.   If you want to participate in the working group, that's great, but please don't present this as a fait accomplis.

The fact is that there are definitely use cases where the MAC address is a useful key to be used for associating the device in the box with a back office database record.   However, it's also almost certainly true that in _every single case_ like this, DUID-LL is a valid identifier to use.

So if we really want to go down the road you're proposing, Simon, I think that the right thing to do is to _require_ that DUID-LL be used instead of DUID-LLT in those cases where it is applicable, and to permit DHCP servers to examine the link layer address contained within the DUID-LL for the purposes of matching records in back office databases that may have been generated by reading bar codes off the side of boxes.

---

From: perl-list <[email-masked]>
Date: Fri, 16 Mar 2012 12:33:58 -0400 (EDT)

> The fact is that there are definitely use cases where the MAC address
> is a useful key to be used for associating the device in the box
> with a back office database record. However, it's also almost
> certainly true that in _every single case_ like this, DUID-LL is a
> valid identifier to use.

DUID-LL - true - the hardware address is in that one .... it cannot be guaranteed that method will be used by the client since there are two others.

---

From: Simon Hobson <[email-masked]>
Date: Fri, 16 Mar 2012 17:12:08 +0000

Ted Lemon wrote:

>>The prohibition of looking into the DUID may be one of the issues. 
>> A DUID-LLT doesn't give you any reliable info, and a DUID-EN gives 
>>you almost nothing (although I suppose vendors could print the EN 
>>part on the box, making it a useful identifier for the 
>>aforementioned workflow).  However, the DUID-LL is defined as 
>>having a current network link address.  One could use that in place 
>>of a MAC address in certain known areas (cable modems, for example. 
>> Use the HFC MAC address to compose the DUID-LL).
>>
>
>That prohibition was against treating the parts of the DUID 
>separately for the purpose of identifying the client.   It was never 
>intended that you couldn't look at it, just that you couldn't 
>extract the MAC address and use it as a client identifier by itself.

That, I have to say is semantic wriggling.

Since the discussion is about the utility of the hardware address for 
various requirements, saying it's in there but you can't extract it 
and look at it is merely an admission that as defined, it is not 
useful for the sort of things people in the real world are wanting to 
do.

Ted Lemon wrote:
>On Mar 16, 2012, at 10:39 AM, Simon Hobson 
><<mailto:[email-masked]>[email-masked]> wrote:
>
>>Also, I think we reached a consensus that in the general case, 
>>there is no way to match IPv4 clients with IPv6 clients. It may be 
>>in some cases (eg by matching port IDs from relay agents), but in 
>>the general case IPv6 clients will be using DUIDs which we are 
>>specifically barred from looking into even if they did contain the 
>>same hardware address as is currently used for the interface.

>This was not a working group discussion; what consensus may have 
>been reached on the ISC DHCP mailing list is not a matter of 
>interest to the working group.   If you want to participate in the 
>working group, that's great, but please don't present this as a fait 
>accomplis.

I did not say it was, did not say otherwise, and did not present it 
as such. What I stated was factually accurate (as far as I recall). 
The only thing I may have left out is "(on the DHCP Users mailing 
list) we reached a consensus (on what users want/need) ..."

If the DHC working group really has no interest in what users think 
then I think that says a lot. Some people who are on the WG were well 
aware of users feelings, now if that never entered any discussion I 
think those people involved perhaps need to consider the function and 
purpose of standards.

Your comment is perhaps valid, but would the current structure still 
work if suddenly a *lot* of users joined the WG to air their views - 
rather than trusting that those who are already on the WG and are 
fully aware of those view might perhaps air them ?

Perhaps I'm reading too much into this, and I really don't want to 
flog what's left of this old equine carcass any more, but your 
attitude does suggest an element of "if you don't air it at the WG we 
don't give a <whatever term you want to use> about what users think 
or need." I hope that's not the case, but it is how it comes across.

>The fact is that there are definitely use cases where the MAC 
>address is a useful key to be used for associating the device in the 
>box with a back office database record.   However, it's also almost 

That may be almost true, but what is equally true is that it is the 
least likely DUID option to be present. My understanding (from 
memory, correct me if I'm wrong) is that on any device with 
persistent storage, use of DUID-LL is deprecated in favour of one of 
the other options. Unless DUID-LL is present from **ALL** devices, 
then it cannot be used to substitute for hardware address (or some 
better identifier).

>So if we really want to go down the road you're proposing, Simon, I 
>think that the right thing to do is to _require_ that DUID-LL be 
>used instead of DUID-LLT in those cases where it is applicable, and 
>to permit DHCP servers to examine the link layer address contained 
>within the DUID-LL for the purposes of matching records in back 
>office databases that may have been generated by reading bar codes 
>off the side of boxes.

That would probably suit *most* use cases people are talking about. 
To suit *all* use cases, you'd also have to mandate that all DHCPv4 
clients also send that option. The chances of getting that passed 
**and** into common usage is probably little different from zero.

But we come back to a strange reluctance to use some simple, 
immutable, predetermined identifier when a more complicated, 
changeable, and unknown one can be used instead. I suspect that if 
you mandated that DUID-LL was always sent then that would satisfy 
most users, and the few remaining onces could work around the 
limitations with some workflow adjustments.
Then what's the next step ? Does a device also send a different 
identifier ? Or do all the other options become deprecated ?

PS - please don't CC me in replies. I'm on the list, if you reply to 
the list then I'll see the reply there.

-- 
Simon Hobson

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Mar 2012 17:26:03 +0000

On Mar 16, 2012, at 12:33 PM, perl-list <[email-masked]<mailto:[email-masked]>> wrote:
DUID-LL - true - the hardware address is in that one ....  it cannot be guaranteed that method will be used by the client since there are two others.

I did address that point later in the message to which you are replying...

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Mar 2012 17:39:21 +0000

> That, I have to say is semantic wriggling.

I wrote the text.   I know what I intended it to mean.

> If the DHC working group really has no interest in what users think then I think that says a lot. Some people who are on the WG were well aware of users feelings, now if that never entered any discussion I think those people involved perhaps need to consider the function and purpose of standards.

The working group is interested in what all users think, not just you.

> Your comment is perhaps valid, but would the current structure still work if suddenly a *lot* of users joined the WG to air their views - rather than trusting that those who are already on the WG and are fully aware of those view might perhaps air them ?

Participation in the working group is down.   More participation would be better.   However, if the form the participation takes is simply "voting," then it's probably better that you don't show up.

> Perhaps I'm reading too much into this, and I really don't want to flog what's left of this old equine carcass any more, but your attitude does suggest an element of "if you don't air it at the WG we don't give a <whatever term you want to use> about what users think or need." I hope that's not the case, but it is how it comes across.

No, that's not my point.   My point is that the fact that some ISC DHCP users agree on something neither means that what they agree on represents a consensus, nor that they've considered all the options.

> That may be almost true, but what is equally true is that it is the least likely DUID option to be present. My understanding (from memory, correct me if I'm wrong) is that on any device with persistent storage, use of DUID-LL is deprecated in favour of one of the other options. Unless DUID-LL is present from **ALL** devices, then it cannot be used to substitute for hardware address (or some better identifier).

We can update that standard as easily as we can define a new option.  So the question is what we want to do, not what the standard currently says.

> That would probably suit *most* use cases people are talking about. To suit *all* use cases, you'd also have to mandate that all DHCPv4 clients also send that option. The chances of getting that passed **and** into common usage is probably little different from zero.

Why is that?   Isn't the DHCPv4 client already sending its MAC address?

> But we come back to a strange reluctance to use some simple, immutable, predetermined identifier when a more complicated, changeable, and unknown one can be used instead.

It's only strange because each time I explain it to you, you complain that I'm not listening.   DUID is supposed to be immutable; if it is not, it's because someone has failed to implement DHCPv6, and has instead implemented something sort of like DHCPv6 that isn't compliant with the standard.   The reason for using a uniform identifier is that resources are allocated to the client on the basis of the identifier it presents, including, potentially, a domain name.   If the client is not consistent as to the identifier it presents, the DHCP server will see a conflict in the use of resources such as domain names in situations where no conflict actually exists.

> I suspect that if you mandated that DUID-LL was always sent then that would satisfy most users, and the few remaining onces could work around the limitations with some workflow adjustments.
> Then what's the next step ? Does a device also send a different identifier ? Or do all the other options become deprecated ?

I'm proposing that if the device can send a DUID-LL, it should.   If it can't, it can use one of the other DUIDs.   I think this addresses your use case without breaking the use cases that DUID was intended to address.   Would you be happy with this solution?

> PS - please don't CC me in replies. I'm on the list, if you reply to the list then I'll see the reply there.

I'm replying to you and CCing the mailing list.   I'm sorry your mail user agent can't tell that both messages are the same message, but it gets really cumbersome to constantly edit headers to satisfy requests like this, so it's traditional on IETF mailing lists to just accept that there will be duplicates and not complain about it.   Personally I would rather that the mailing list software add a Reply-To: header, but there are problems with that, particularly since non-members frequently post to IETF mailing lists.

---

From: David Farmer <[email-masked]>
Date: Fri, 16 Mar 2012 13:19:30 -0500

We should not back away for DUID, it was created for good reason, it is 
the right answer for the long term.  The fundamental problem wasn't 
fixing the client identifier problem with DUID.  The fundamental problem 
was thinking that DHCPv6 and DHCPv4 can be ships in the night.

Most of us are not managing separate IPv6 networks and IPv4 networks 
that can have client identifiers that are ships in the night.  We are 
running Dual-Stack IPv4/IPv6 networks.

In the short run I believe we need a DHCPv6 relay option to included the 
hardware address in the information going to the DHCPv6 server, this 
provides network operators a partial solution to the immediate 
operational issues, and they can have full control of the implementation 
of such a solution.

However, in the longer run I believe we should reexamine and maybe 
clearly specify what the proper Dual-Stack DHCP client behavior should 
be.  This could include requiring DUID-LL or something like 
draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 on the DHCPv6 client 
side.  It could require the use of the same DUID on the DHCPv4 client side.

Personally, I think I would prefer the DHCPv6 client to include a list 
of all possible hardware addresses.  This wouldn't require any changes 
to DHCPv4 client code and would still allow DUID to work as intended, 
while allowing correlation of all IPv4 and IPv6 addresses assigned to an 
individual client regardless of how many interfaces or network prefixes 
it is using.  I'm not sure the proposal to just use DUID-LL will 
actually allow you to correlate all the IPv4 address of a 
multi-interface host.  You would get all the IPv6 addresses which is why 
DUID was created.

On 3/16/12 11:33 CDT, perl-list wrote:
> DUID-LL - true - the hardware address is in that one .... it cannot be
> guaranteed that method will be used by the client since there are two
> others.
>
>

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 16 Mar 2012 14:42:14 -0400

Yes! I was going to suggest we look at 3315 and revise the DUID-LL description to make it more likely to be used. From a quick look at some data I have for a few thousand clients (mostly iphones, ipads, etc) it didn't look like any where using DUID-LL which seemed a bit odd for these devices? Would anyone replace the NIC "card" in these?

Sent from my iPad

On Mar 16, 2012, at 11:47 AM, "Ted Lemon" <[email-masked]> wrote:

> On Mar 16, 2012, at 10:39 AM, Simon Hobson <[email-masked]> wrote:

---

From: Andre Kostur <[email-masked]>
Date: Fri, 16 Mar 2012 12:25:24 -0700

Probably not, but they'd presumably be following the text that said that if
the device has persistent storage, that the DUID-LLT was the preferred DUID
to use.

On Fri, Mar 16, 2012 at 11:42, Bernie Volz (volz) <[email-masked]> wrote:

> Yes! I was going to suggest we look at 3315 and revise the DUID-LL
> description to make it more likely to be used. From a quick look at some
> data I have for a few thousand clients (mostly iphones, ipads, etc) it
> didn't look like any where using DUID-LL which seemed a bit odd for these
> devices? Would anyone replace the NIC "card" in these?
>
> Sent from my iPad
>
> This was not a working group discussion; what consensus may have been
> reached on the ISC DHCP mailing list is not a matter of interest to the
> working group.   If you want to participate in the working group, that's
> great, but please don't present this as a fait accomplis.
>
>  The fact is that there are definitely use cases where the MAC address is
> a useful key to be used for associating the device in the box with a back
> office database record.   However, it's also almost certainly true that in
> _every single case_ like this, DUID-LL is a valid identifier to use.
>
> think that the right thing to do is to _require_ that DUID-LL be used
> instead of DUID-LLT in those cases where it is applicable, and to permit
> DHCP servers to examine the link layer address contained within the DUID-LL
> for the purposes of matching records in back office databases that may have
> been generated by reading bar codes off the side of boxes.
>

-- 
 *Andre Kostur*

---

From: Niall O'Reilly <[email-masked]>
Date: Fri, 16 Mar 2012 20:18:37 +0000

> while in the general case, only one (the least likely to be found) of

	Thanks for the summary, Simon.
	+1 from me.

	Niall O'Reilly

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Fri, 16 Mar 2012 22:19:17 +0200

Fyi, we met the following issue regarding the DUID:

We use a common Framed-Interface-Id for our subscribers which is defined through radius 
and then passed to the managed CPEs.

DUID-LL didn't work for us because of the WAN link-layer address being generated using the 
common Framed-Interface-Id.

DUID-LLT didn't also work for us because if two CPEs that share a common WAN link-layer 
address reboot (or reset to factory defaults) at the same time, their time will be also 
the same.

So we ended up using DUID-EN (the vendor refused to use the LAN link-layer address for 
DUID-LL, although i don't know if that is applicable).

--
Tassos

Andre Kostur wrote on 16/3/2012 21:25:
> Probably not, but they'd presumably be following the text that said that if the device 
> has persistent storage, that the DUID-LLT was the preferred DUID to use.
>
> On Fri, Mar 16, 2012 at 11:42, Bernie Volz (volz) <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Yes! I was going to suggest we look at 3315 and revise the DUID-LL description to
>     make it more likely to be used. From a quick look at some data I have for a few
>     thousand clients (mostly iphones, ipads, etc) it didn't look like any where using
>     DUID-LL which seemed a bit odd for these devices? Would anyone replace the NIC
>     "card" in these?
>
>     Sent from my iPad
>
>     On Mar 16, 2012, at 11:47 AM, "Ted Lemon" <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>>>     Also, I think we reached a consensus that in the general case, there is no way to
>>>     match IPv4 clients with IPv6 clients. It may be in some cases (eg by matching port
>>>     IDs from relay agents), but in the general case IPv6 clients will be using DUIDs
>>>     which we are specifically barred from looking into even if they did contain the
>>     This was not a working group discussion; what consensus may have been reached on
>>     the ISC DHCP mailing list is not a matter of interest to the working group.   If
>>     you want to participate in the working group, that's great, but please don't
>>     present this as a fait accomplis.
>>
>>     The fact is that there are definitely use cases where the MAC address is a useful
>>     key to be used for associating the device in the box with a back office database
>>     record.   However, it's also almost certainly true that in _every single case_ like
>>     this, DUID-LL is a valid identifier to use.
>>
>>     So if we really want to go down the road you're proposing, Simon, I think that the
>>     right thing to do is to _require_ that DUID-LL be used instead of DUID-LLT in those
>>     cases where it is applicable, and to permit DHCP servers to examine the link layer
>>     address contained within the DUID-LL for the purposes of matching records in back
>>     office databases that may have been generated by reading bar codes off the side of
>>     boxes.
>>
>>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: perl-list <[email-masked]>
Date: Fri, 16 Mar 2012 16:19:45 -0400 (EDT)

David - you have hit the proverbial nail squarely on the head with this. That is the exact problem we are dealing with. Operators, during this time of transition/dual stacking MUST have access to the hardware address at least in some cases. I don't understand what all the animosity toward this is... I am not understanding why it wasn't included in the first place. Wouldn't more information be preferable to less? I, for one, do not think that any of the other IDs need to go away. DHCPv4 used the client id to allocate addresses. The standard provided chaddr only for informational purposes. Information is good - the more of it network operators have, the better. 

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

> From: "David Farmer" <[email-masked]>
> Cc: "Ted Lemon" <[email-masked]>, "dhcwg" <[email-masked]>,
> "David Farmer" <[email-masked]>
> Sent: Friday, March 16, 2012 2:19:30 PM
> Subject: Re: [dhcwg] DUID vs MAC address: the fight of the century!

---

From: "Weil, Jason" <[email-masked]>
Date: Fri, 16 Mar 2012 16:23:54 -0400

I actually prefer DUID-LL and I know of many home gateways that will be based on this option. That being said there are a couple of options allowed in the Cablelabs eRouter spec as shown below. You will notice the one that is not an option is DUID-LLT.

Jason

From eROUTER Spec:

A Client Identifier option containing the DHCP Unique Identifier (DUID) for this eRouter (as specified by
[RFC 3315]), the DUID should be formatted as follows:
a. The eRouter MUST use a DUID that is one of DUID-LL, DUID-EN or DUID_UUID type and;
b. The eRouter MUST use a DUID that is persistent across administrative reset or reboot following a loss of
power per [RFC 6204] W-6.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Friday, March 16, 2012 2:42 PM
To: Ted Lemon
Cc: [email-masked]
Subject: Re: [dhcwg] DUID vs MAC address: the fight of the century!

Sent from my iPad

On Mar 16, 2012, at 11:47 AM, "Ted Lemon" <[email-masked]<mailto:[email-masked]>> wrote:
On Mar 16, 2012, at 10:39 AM, Simon Hobson <[email-masked]<mailto:[email-masked]>> wrote:
Also, I think we reached a consensus that in the general case, there is no way to match IPv4 clients with IPv6 clients. It may be in some cases (eg by matching port IDs from relay agents), but in the general case IPv6 clients will be using DUIDs which we are specifically barred from looking into even if they did contain the same hardware address as is currently used for the interface.

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

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Niall O'Reilly <[email-masked]>
Date: Fri, 16 Mar 2012 20:27:37 +0000

On 16/03/12 15:47, Ted Lemon wrote:
> DHCP servers to examine the link layer address contained within the
> DUID-LL for the purposes of matching records in back office databases
> that may have been generated by reading bar codes off the side of boxes.

	That solution appeals to me.

	Niall O'Reilly

---

From: Simon Hobson <[email-masked]>
Date: Fri, 16 Mar 2012 20:30:52 +0000

Ted Lemon wrote:

>  > If the DHC working group really has no interest in what users 
>think then I think that says a lot. Some people who are on the WG 
>were well aware of users feelings, now if that never entered any 
>discussion I think those people involved perhaps need to consider 
>the function and purpose of standards.
>
>>  Your comment is perhaps valid, but would the current structure 
>>still work if suddenly a *lot* of users joined the WG to air their 
>>views - rather than trusting that those who are already on the WG 
>>and are fully aware of those view might perhaps air them ?
>
>Participation in the working group is down.   More participation 
>would be better.   However, if the form the participation takes is 
>simply "voting," then it's probably better that you don't show up.
>
>>attitude does suggest an element of "if you don't air it at the WG 
>>we don't give a <whatever term you want to use> about what users 
>>think or need." I hope that's not the case, but it is how it comes 
>>across.
>
>No, that's not my point.   My point is that the fact that some ISC 
>DHCP users agree on something neither means that what they agree on 
>represents a consensus, nor that they've considered all the options.

Well sticking to the specific point, there was a LOT of discussion, I 
do believe all options were raised, and as I recall the summary, 
there was at the very least a general agreement along the lines that 
<something> similar to the hardware option in DHCPv4 was required for 
many usage cases, and having it was unlikely to break things for 
those who don't need it.
So what's being discussed isn't just a case of "what I want" - it's 
clear from the length of this thread that a significant proportion of 
other users "want" this.

I can't speak for anyone else, but I do not have the time spare to 
make a good contribution - hence trying to stay out of the way. As 
you suggest, I doubt I could make a particularly positive 
contribution by joining the WG.
Lest it be thought that I don't value the time and effort people are 
putting in (including by yourself), I can assure you that is not the 
case.

>Why is that?   Isn't the DHCPv4 client already sending its MAC address?

Yes, a DHCPv4 client does send it's MAC address. But, according to 
RFC3315, we are explicitly not allowed to compare that with a DUID :
>Clients and servers MUST treat DUIDs as opaque values and MUST only 
>compare DUIDs for equality.  Clients and servers MUST NOT in any 
>other way interpret DUIDs.

As I read that, it says we can compare a DUID with another DUID for 
equality<period>. Although we know that a DUID-LL contains the 
hardware address, we are expressly forbidden from extracting it and 
comparing with (say) a hardware address from elsewhere. A DUID-LL 
value will **always** fail an equality test with a DHCPv4 Hardware 
Address field - 2 octet DUID type, plus 2 octet hardware type, plus 
hardware address vs 1 byte hardware type plus hardware address.

It may not be what you intended, but that is what is written in RFC 
3315. Some rewording could fix that, but would then dilute the 
message on GUIDs being opaque.

But in any case, DUID-LL may not be the same as the Hardware Address 
sent by a DHCPv4 client on the same interface.

>changeable, and unknown one can be used instead.
>
>It's only strange because each time I explain it to you, you 
>complain that I'm not listening.   DUID is supposed to be immutable; 
>if it is not, it's because someone has failed to implement DHCPv6, 
>and has instead implemented something sort of like DHCPv6 that isn't 
>compliant with the standard.

No, that is **NOT** true. I'm sorry, and I'm really really trying 
hard not to be argumentative, but others have also pointed out the 
fallacy of this. On ANY desktop system, if your user wipes their 
system and installs a fresh installation (of the same or a different 
OS) then the DUID* will most likely change - even a DUID-LL may 
change.
Having a system which runs multiple OSs is most likely to result in 
different GUIDs* in the different OSs.
Having a system that netboots (eg PXE followed by a full OS) will 
most likely mean different GUID*s.
In the general case, to have these different setups all use the same 
persistent GUID means operator/admin intervention - to save the DUID 
and/or copy it from one system to another.
* Unless using DUID-LL, and even that may change if the hardware has 
changed or the clients choose different interfaces as a base.

And, you keep refusing to see (or accept) that a DUID-LLT is not 
known before the OS has booted and generated it. A DUID-EN probably 
is, hopefully that would be printed on the box in future.

My experience is that changes to the (fixed) networking hardware is 
quite rare these days - certainly far less common than the software 
changes I've pointed out. Even wireless is less volatile than it used 
to be since so many systems have that built in as well.

None of that will change without a standardised and ubiquitous 
machine level storage where a DUID can be put which will be 
completely independent of OS changes/re-installs etc. If such a 
facility came to pass, then that could remove much of the case for 
something "like a hardware address" in the DHCP packets - at least 
for DHCPv6 clients.
In fact, such a ubiquitous and unique identifier would solve many 
other ID problems - not just DHCP clients.

And yes, you would be right to point out that this also applies to 
things like SSH keys etc.

>I'm proposing that if the device can send a DUID-LL, it should.   If 
>it can't, it can use one of the other DUIDs.   I think this 
>addresses your use case without breaking the use cases that DUID was 
>intended to address.   Would you be happy with this solution?

It would for me - I think. I'm struggling to think of any situations 
where a DUID-LL isn't possible (no hardware address) but the issue 
applies. It does still leave the issue of where DUID-LL doesn't match 
the Hardware Address - which will apply to 50% of interfaces on 
dual-interface devices, 66% of interfaces on triple-interface 
devices, etc. Most devices I deal with (and this applies to) are 
single interface - though even that is getting less common with 
wireless becoming common on printers.

David Farmer wrote:
>We should not back away for DUID, it was created for good reason, it 
>is the right answer for the long term.  The fundamental problem 
>wasn't fixing the client identifier problem with DUID.  The 
>fundamental problem was thinking that DHCPv6 and DHCPv4 can be ships 
>in the night.
>
>that can have client identifiers that are ships in the night.  We 
>are running Dual-Stack IPv4/IPv6 networks.

I think that is a good summary of the problem. But it's not just DHCP 
- many workflows have a requirement for a device identifier, which in 
many cases can be a hardware address when that's already being used 
for part of the network control/admin.

>clearly specify what the proper Dual-Stack DHCP client behavior 
>should be.

Yes.
However, there is the fundamental problem that you stand little 
chance now of changing common DHCPv4 client behavior - there are just 
too many devices (particularly embedded ones) which will never be 
changed*. Stuff like desktops and smartphones/tablets/etc might 
change, but even that's not guaranteed**.

It would be great to end up in a world where all new devices come 
with <some unique and immutable ID> on the back and on the outside of 
the packaging **AND** available in a standardised way to any software 
running on it. Some systems can have their asset tag (manufacturer 
serial number) read through software (effectively analogous to 
DUID-EN) - but that is not ubiquitous, nor I suspect standardised in 
implementation.

A typical use-case for me is (eg) getting a new printer in through 
the door, bung it's ID into my config, and when it's plugged in it 
will appear on the network at the address I want. I wouldn't 
necessarily see the printer if it was at a different site - so 
getting the user to give me it's ID would be sufficient - otherwise 
I'd have to (for example) trawl the DHCP logs to find it (and then 
wait for it to change it's settings). From comments, I believe that 
is far from a unique situation.
At present, hardware address is probably the least bad identifier. 
Other than DUID-LL, non of the others is immutable, nor are any of 
them known in advance (and so cannot be put either on the equipment 
or it's packaging).

* Even on my small network, I have multiple devices which are "out of 
support" and for which there will not be any firmware updates.

** Look at the trouble Microsoft have had persuading people to leave 
Windows XP behind. And (through work) I still know of clients running 
Win98 and Mac OS 9 ! True that's not a large proportion, but usually 
the network problems are caused by the minority of devices.

Bernie Volz (volz) wrote:

>From a quick look at some data I have for a few thousand clients 
>(mostly iphones, ipads, etc) it didn't look like any where using 
>DUID-LL which seemed a bit odd for these devices? Would anyone 
>replace the NIC "card" in these?

But they have persistent storage. From RFC 3315 :
>DUID-LL is recommended for devices that ... do not have nonvolatile, 
>writable stable storage.

While it does not say they cannot use it, it is suggestive that they 
should use a different type because they have a means of storing it.

Out of interest, what types are most devices using ? I'm guessing 
DUID-LLT is most common ? Perhaps DUID-EN for some types.

PS - I don't think the title is quite right. This isn't a fight for 
one *OR* the other.

-- 
Simon Hobson

---

From: Niall O'Reilly <[email-masked]>
Date: Fri, 16 Mar 2012 20:45:17 +0000

On 16/03/12 20:30, Simon Hobson wrote:
> PS - I don't think the title is quite right. This isn't a fight for one
> *OR* the other.

	Absolutely!

	/Niall

---

From: Niall O'Reilly <[email-masked]>
Date: Fri, 16 Mar 2012 21:33:01 +0000

> +1 from me.

	Not a one-liner this time.

	I haven't seen mention of eduroam as a use case, so here goes.

	Eduroam is an important use-case for us, and likely also for a
	sizeable (http://www.eduroamus.org/eduroam_international_map)
	and growing higher education enterprise-network community.

	We need to be able to identify IP addresses of whichever family
	with individual customers, and to be able to review that
	identification retrospectively for a number of months.  We have
	a pair of transactions which we need to associate:
	authentication for access to the network, and address
	assignment for effective use of that network.

	Today, logs from the radius server used for 802.1x
	authentication and from the DHCP (v4) server can be joined
	using the hardware address.  An opaque identifier, such as
	seems to be preferred for DHCPv6 obstructs this kind of
	administrative interoperation between authentication and
	address-assignment protocols.  We're not planning to
	redesign our 802.1x infrastructure.  We could invent a
	work-around by triggering some kind of complementary
	transaction (using SNMP perhaps) whenever a lease is
	committed, but that would be egregiously clumsy compared to
	having the DHCP transaction just carry the data we need.

	Best regards,
	Naill O'Reilly

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Mar 2012 21:41:21 +0000

On Mar 16, 2012, at 4:30 PM, Simon Hobson <[email-masked]<mailto:[email-masked]>>
 wrote:
It would for me - I think. I'm struggling to think of any situations where a DUID-LL isn't possible (no hardware address) but the issue applies. It does still leave the issue of where DUID-LL doesn't match the Hardware Address - which will apply to 50% of interfaces on dual-interface devices, 66% of interfaces on triple-interface devices, etc. Most devices I deal with (and this applies to) are single interface - though even that is getting less common with wireless becoming common on printers.

This doesn't matter for the box scanning case, because typically if there are multiple fixed network interfaces in a device, the box it comes in will list the MAC addresses of each interface, not just one.   So the case where it fails is the DHCPv4<->DHCPv6 identification scenario.

I think this argues pretty strongly for the relay agent option, despite the patent.

---

From: [email-masked]
Date: Sat, 17 Mar 2012 09:41:09 +0100 (CET)

> PS - I don't think the title is quite right. This isn't a fight for 

Absolutely agreed. And +1 on your whole message.

---

From: perl-list <[email-masked]>
Date: Mon, 19 Mar 2012 09:00:05 -0400 (EDT)

> From: "Simon Hobson" <[email-masked]>
> To: [email-masked]
> Sent: Friday, March 16, 2012 4:30:52 PM

> Well sticking to the specific point, there was a LOT of discussion
> ... <snip> ....

> Christmas stocking fillers. Some available as e-books.

indeed! +1 on your whole message from me as well!