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

[Andre Kostur <[e-mail]>]

On Thu, Jul 12, 2012 at 12:30 PM, Marc Perea <[e-mail]> 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 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?

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