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

>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: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Andre Kostur
Sent: Thursday, July 12, 2012 3:40 PM
To: Marc Perea
Cc: dhcwg@ietf.org
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 <marccp@srttel.com> wrote:
>
> 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 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.
>
> 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?

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
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg