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

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

> From: "Marc Perea" <marccp@srttel.com>
> To: dhcwg@ietf.org
> 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?
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg