Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt

From: "Marc Perea" <[email-masked]>
Date: Thu, 12 Jul 2012 14:30:17 -0500

While true that the primary key of the DHCP server lease would be client id, in the cases that this draft was intended to support the MAC is a known indentifier readily printed on the outside of ethernet packaging and on labels while hardware is powered off and not connected to the network. That MAC is directly tied to a client/customer in many operator environments, whether it sends client-id or not. From the operator perspective, we don't really care whether the DHCProtocol uses client-id or MAC to index it's internal database - what we are concerned with is matching a MAC in existing non-DHCP database to a client/customer so that we can match a v4 address and a v6 address (or several of each) to an individual client/customer. The solution is intended to have the relay grab the MAC from the v6 packet and add that as an option (hint) to the DHCP server. Such implementation fills the need of the problem at hand, only requiring changes be made to relay agents and DHCP servers. WG members represent most of the DHCPv6 server software and relay hardware/software suppliers. In short, the WG is both willing and able to effect the changes presented in the draft.
 
It sounds like you're contending that the DHCP server won't be able to know which v4 == which v6 client, and I don't know if that's a problem. The problem this is intended to solve is that without supporting the link layer address that is readily available before connecting a device to a network or even turning it on, there is no way to set the server in advance to hand out known addresses that are intended for a specific client. For network access control and some tracking mechanisms, this is a big problem. By adding MAC to the v6 exchange, operators are able to match up MAC tracking databases, where MAC is an important index that they care about. The fact that the DHCP server uses or doesn't use it is irrelevant.
 
We've presented what use case caused this draft to come into existence, and I understand the desire to make a protocol robust, but can you present a use case that relates here so that I can understand what you'd additionally like to achieve?

---

From: Andre Kostur <[email-masked]>
Date: Thu, 12 Jul 2012 12:40:24 -0700

> We've presented what use case caused this draft to come into existence, and I understand the desire to make a protocol robust, but can you present a use case that relates here so that I can underst…

Ok, if we're restricting to ISP environments, why not mandate in such
environments that they should be using the Remote ID (RFC 4649) to
specify the downstream "client".  Note that in DOCSIS environments,
this is already happening.  (Just not in RFC 4649 form... but in an
enterprise-specific option 17).

--
Andre Kostur

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jul 2012 19:49:59 +0000

On Jul 12, 2012, at 3:40 PM, Andre Kostur wrote:

It's my understanding that the main motivator for this draft is use in corporate IT departments that inventory machines by MAC address.   I guess it would also be useful for ISPs, but that's certainly not the use case that I've heard mentioned most.

---

From: "Eustace, Glen" <[email-masked]>
Date: Thu, 12 Jul 2012 20:23:23 +0000

As one of these IT departments, I thought that some empirical data might be useful.

We have now got ISC dhcpd running on our main campus and I have just completed adding native IPv6 to the majority of networks.  We do NOT yet have DUIDs stored in our databases but do have the MAC address for the primary NIC for all University owned equipment.

I have the  hardware-ethernet included in each host declaration for both IPv4 and IPv6.  Using the ISC fudge of deconstructing the type 1 DUID, we have 1224 matches out of 1693 active leases.  Whilst not perfect, it is actually better than I expected and for us does add value.

I have not yet attempted to determine why we failed to match the remaining leases, could be a number of reasons

  1.  Private equipment for which we do not have a MAC in the DB
  2.  The DUID generated used a MAC we don't have in the DB
  3.  The MAC we have is wrong.
  4.  etc

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Glen Eustace, Infrastructure Development Engineer (BC/DR)
Information Technology Service, Massey University PN460
Tennent Drive, Palmerston North, New Zealand
Ph: +64-6-3569099 x 81005, Fax: +64-6-3505607, Mob: +64-27-4500321

From: "Ted com>" <[email-masked]<mailto:[email-masked]>>
Date: Thu, 12 Jul 2012 19:49:59 +0000
To: Andre Kostur <[email-masked]<mailto:[email-masked]>>
Cc: "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>, Marc Perea <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt

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

---

From: "Marc Perea" <[email-masked]>
Date: Thu, 12 Jul 2012 16:24:11 -0500

Indeed. Although I work for an ISP, and our intent on v6 is to use option 82 to identify endpoints, including for the purposes of PD where we won't care what LL address is presented from the WAN of the device, this work is useful when I wear the corporate hat, or the educational lab services hat, or the captive portal for wifi hat. I'm not necessarily interested in restricting the use of the mechanism we're attempting to push forward here - I'm trying to understand what real world scenario could exist that justifies expanding the scope of the draft. I feel that the work and scope are currently justified and real - I'm not against expanding both, but I'd like to know it's being done to solve a real problem. Can you elaborate?

>>> Ted Lemon <[email-masked]> 7/12/2012 2:49 PM >>>

---

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

It is useful for ISPs where some of their network types don't have the circuit ID available, or there is no circuit ID (wireless) or the Circuit ID is dynamic. In these cases, they tend to use the Link Layer address for customer identification. 
----- Original Message -----

> From: "Marc Perea" <[email-masked]>
> To: "Andre Kostur" <[email-masked]>, "Ted Lemon"
> <[email-masked]>
> Cc: "<[email-masked]>" <[email-masked]>
> Sent: Thursday, July 12, 2012 5:24:11 PM
> Subject: Re: [dhcwg] I-D
> Action:draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt

> Indeed. Although I work for an ISP, and our intent on v6 is to use
> option 82 to identify endpoints, including for the purposes of PD
> where we won't care what LL address is presented from the WAN of the
> device, this work is useful when I wear the corporate hat, or the
> educational lab services hat, or the captive portal for wifi hat.
> I'm not necessarily interested in restricting the use of the
> mechanism we're attempting to push forward here - I'm trying to
> understand what real world scenario could exist that justifies
> expanding the scope of the draft. I feel that the work and scope are
> currently justified and real - I'm not against expanding both, but
> I'd like to know it's being done to solve a real problem. Can you
> elaborate?

> It's my understanding that the main motivator for this draft is use
> in corporate IT departments that inventory machines by MAC address.
> I guess it would also be useful for ISPs, but that's certainly not
> the use case that I've heard mentioned most.

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

---

From: perl-list <[email-masked]>
Date: Fri, 13 Jul 2012 09:07:08 -0400 (EDT)

Some equipment doesn't use any mac at all to generate the DUID which is perfectly acceptable in the related RFC. If the DUID always used the mac, then we wouldn't need this draft at all. 

> I have not yet attempted to determine why we failed to match the
> remaining leases, could be a number of reasons

---

From: perl-list <[email-masked]>
Date: Fri, 13 Jul 2012 09:08:34 -0400 (EDT)

This is exactly the ISP case. Administrator doesn't really care how the DHCP server is tracking leases, only that there is some mechanism to correlate between v4 and v6. 

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

> To: [email-masked]
> Sent: Thursday, July 12, 2012 3:30:17 PM
> Subject: Re: [dhcwg] I-D Action:
> draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt

> While true that the primary key of the DHCP server lease would be
> client id, in the cases that this draft was intended to support the
> MAC is a known indentifier readily printed on the outside of
> ethernet packaging and on labels while hardware is powered off and
> not connected to the network. That MAC is directly tied to a
> client/customer in many operator environments, whether it sends
> client-id or not. From the operator perspective, we don't really
> care whether the DHCProtocol uses client-id or MAC to index it's
> internal database - what we are concerned with is matching a MAC in
> existing non-DHCP database to a client/customer so that we can match
> a v4 address and a v6 address (or several of each) to an individual
> client/customer. The solution is intended to have the relay grab the
> MAC from the v6 packet and add that as an option (hint) to the DHCP
> server. Such implementation fills the need of the problem at hand,
> only requiring changes be made to relay agents and DHCP servers. WG
> members represent most of the DHCPv6 server software and relay
> hardware/software suppliers. In short, the WG is both willing and
> able to effect the changes presented in the draft.

> It sounds like you're contending that the DHCP server won't be able
> to know which v4 == which v6 client, and I don't know if that's a
> problem. The problem this is intended to solve is that without
> supporting the link layer address that is readily available before
> connecting a device to a network or even turning it on, there is no
> way to set the server in advance to hand out known addresses that
> are intended for a specific client. For network access control and
> some tracking mechanisms, this is a big problem. By adding MAC to
> the v6 exchange, operators are able to match up MAC tracking
> databases, where MAC is an important index that they care about. The
> fact that the DHCP server uses or doesn't use it is irrelevant.

> We've presented what use case caused this draft to come into
> existence, and I understand the desire to make a protocol robust,
> but can you present a use case that relates here so that I can
> understand what you'd additionally like to achieve?

---

From: perl-list <[email-masked]>
Date: Fri, 13 Jul 2012 09:10:14 -0400 (EDT)

Not all downstream equipment supports Remote ID. Not all network setups have a circuit ID either.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 13 Jul 2012 19:48:46 +0000

>Ok, if we're restricting to ISP environments, why not mandate in
>such environments that they should be using the Remote ID (RFC
>4649) to specify the downstream "client".  Note that in DOCSIS
>environments, this is already happening.  (Just not in RFC 4649
>form... but in an enterprise-specific option 17).

And as I pointed out a few days ago, DOCSIS could care less about the CPE mac address. The important mac address printed on the box is for the CM, not the CPE. In DOCSIS, it wants to know the CM's mac address for DHCPv6 CPE requests, not the CPE's mac address. 

So, this draft could be used by DOCSIS only for the CM's DHCPv6 requests and something else would still be needed for when the CPE did DHCPv6 to provide the CM's mac-address. DOCSIS already solves both issues with its Vendor Specific Option definitions.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andre Kostur
Sent: Thursday, July 12, 2012 3:40 PM
To: Marc Perea
Cc: [email-masked]
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt

On Thu, Jul 12, 2012 at 12:30 PM, Marc Perea <[email-masked]> wrote:
> MAC is a known indentifier readily printed on the outside of ethernet 
> packaging and on labels while hardware is powered off and not 
> connected to the network. That MAC is directly tied to a 
> client-id or not. From the operator perspective, we don't really care 
> whether the DHCProtocol uses client-id or MAC to index it's internal 
> database - what we are concerned with is matching a MAC in existing 
> non-DHCP database to a client/customer so that we can match a v4 
> address and a v6 address (or several of each) to an individual 
> only requiring changes be made to relay agents and DHCP server
 s. WG members represent most of the DHCPv6 server software and relay hardware/software suppliers. In short, the WG is both willing and able to effect the changes presented in the draft.
> We've presented what use case caused this draft to come into existence, and I understand the desire to make a protocol robust, but can you present a use case that relates here so that I can underst…

Ok, if we're restricting to ISP environments, why not mandate in such environments that they should be using the Remote ID (RFC 4649) to specify the downstream "client".  Note that in DOCSIS environments, this is already happening.  (Just not in RFC 4649 form... but in an enterprise-specific option 17).

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 13 Jul 2012 19:59:47 +0000

You might repeat this test using the IPv6 source address of the client or Relay's (closest to client) peer-address field to extract the IPv6 address, which if a link-local, should contain the EUI-64 identifier which you can turn back into a mac-address.

I suspect that this technique will be a much more reliable indication of the current interface's mac-address.

Note: I am not suggesting that we not do this draft because of the above.

-          Bernie

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eustace, Glen
Sent: Thursday, July 12, 2012 4:23 PM
To: Ted Lemon
Cc: <[email-masked]>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt

---

From: "Eustace, Glen" <[email-masked]>
Date: Sun, 15 Jul 2012 20:45:02 +0000

> Some equipment doesn't use any mac at all to generate the DUID which is perfectly acceptable in the related RFC.
> If the DUID always used the mac, then we wouldn't need this draft at all.

Correct but in an Enterprise environment like ours, the majority of clients do. I haven't seen any that don't yet.  I just thought it might be interesting to see in how many cases the MAC used for IPv4 actually was successful in identifying the client (for back office purposes)

---

From: perl-list <[email-masked]>
Date: Mon, 16 Jul 2012 08:53:23 -0400 (EDT)

I can't remember which, but it is either Mac OS or windows 7 that use a random mac to generate the link local address and in turn use the link local to generate the DUID (or the reverse - in any case, it wasn't the mac of the interface). D-Link routers use no mac at all and just randomly generate the DUID. Neither of those device's macs can be gotten from the DUID. 

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

> From: "Glen Eustace" <[email-masked]>
> To: "dhcwg" <[email-masked]>
> Sent: Sunday, July 15, 2012 4:45:02 PM

> > Some equipment doesn't use any mac at all to generate the DUID
> > which is perfectly acceptable in the related RFC.

> Correct but in an Enterprise environment like ours, the majority of
> clients do. I haven't seen any that don't yet. I just thought it
> might be interesting to see in how many cases the MAC used for IPv4
> actually was successful in identifying the client (for back office
> purposes)

---

From: Tim Chown <[email-masked]>
Date: Mon, 16 Jul 2012 14:24:13 +0100

Hi Glen,

Does that mean all your devices/OSes are by default using DUID-LL?  The spec says that the client must use *a* MAC address; it may not happen to pick the one corresponding to the interface that the query comes from. 

It would be very interesting to see other enterprises who are using DHCPv6 reporting what they see. And interesting to also note how often observed DUIDs change over time, e.g. from dual-boot systems.

The relay function seems useful to me. In a typical campus environment that we'd be interested in, all requests would be forwarded by a relay, thus client support would not be essential in our environment.

It would seem very likely the proposed draft would be used by some enterprise admins to try to perform the same type of "accountability" that exists for DHCPv4 with DHCPv6.  That's a question that frequently crops up from new sites considering IPv6 deployment.

Tim

On 12 Jul 2012, at 21:23, Eustace, Glen wrote:

> Private equipment for which we do not have a MAC in the DB
> The DUID generated used a MAC we don't have in the DB
> The MAC we have is wrong.
> etc
> -- 
> From: "Ted com>" <[email-masked]>
> To: Andre Kostur <[email-masked]>
> Cc: "<[email-masked]>" <[email-masked]>, Marc Perea <[email-masked]>
> _______________________________________________ dhcwg mailing list [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Eustace, Glen" <[email-masked]>
Date: Mon, 16 Jul 2012 22:38:33 +0000

Hi Tim,

> Does that mean all your devices/OSes are by default using DUID-LL?  The spec says that the client
> must use *a* MAC address; it may not happen to pick the one corresponding to the interface that
> the query comes from.

No, the vast majority are DUID-LLT, there are some DUID-LLs.   The version of the ISC DHCPv6 code I am running deconstructs the DUID and attempts to match the MAC address with the host hardware-addres if a host DUID isn't specified in the config file, this is a hack but is proving useful as we do not have the DUIDs in our database yet still want to try to match the lease to the client primarily so that the forward DDNS uses the official name of the client.

> It would be very interesting to see other enterprises who are using DHCPv6 reporting what they see.
> And interesting to also note how often observed DUIDs change over time, e.g. from dual-boot systems.

I haven't had a chance to look at anything like this yet.

> The relay function seems useful to me. In a typical campus environment that we'd be interested in
> all requests would be forwarded by a relay, thus client support would not be essential in our environment.

Same here but for the hosts in the same network as the DHCP servers.

> It would seem very likely the proposed draft would be used by some enterprise admins to try to perform
> the same type of "accountability" that exists for DHCPv4 with DHCPv6.  That's a question that frequently
> crops up from new sites considering IPv6 deployment.

I think if is was up to me, I'd be pushing for SLAAC for the majority of our clients but it isn't and the security team wants 'accountability' just like they think they have with IPv4. So I have to do my best to get DHCPv6 doing something similar to DHCPv4.

Glen.

---

From: Hans Liu <[email-masked]>
Date: Tue, 17 Jul 2012 09:12:02 +0800

D-Link DIR-series routers should use DUID-LL by default.

Regards,
Hans

On Mon, Jul 16, 2012 at 8:53 PM, perl-list <[email-masked]> wrote:
> I can't remember which, but it is either Mac OS or windows 7 that use a
> random mac to generate the link local address and in turn use the link local
> to generate the DUID (or the reverse - in any case, it wasn't the mac of the
> interface).  D-Link routers use no mac at all and just randomly generate the
> DUID.  Neither of those device's macs can be gotten from the DUID.
>