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

["Marc Perea" <[e-mail]>]

I'm new to posting on this list, but have followed closely this particular problem space for quite a while.
 
>It seems to me there are two use cases here, which argue for different
>uses of the option:

I  think the WG would argue that there are many use cases for DHCP, two of which you indicate here.

>The first use case is to allow the DHCP server to identify the client by
>its hardware address, the same as it could under DHCPv4, even when there
>is a relay involved.  The option takes the place of the DHCPv4 chaddr
>field or the layer 2 source address, and is needed when and only when
>there is a relay involved.
 
There's been quite a lot of misconception (including myself) about what the chaddr represents. It is both a primary key for spec following DHCP servers in the absence of client id in dhcpv4, and a (semi) unique identifier that many of us used in our daily activities and workflow processes. I believe that from the WG perspective, with the scope of identifying what a protocol should support, Ted in particular often specifies the importance of unique identifiers from the protocol perspective. We should appreciate that, because that's important to the stability of the protocol. On the other hand, many of us have currently broken workflow and tracking because the mac address isn't readily available today on v6, and sometimes that's the best (or only) way to reasonably match identification of an endpoint capable of v4 + v6. Some of us are choosing not to implement v6 for this specific feature lack. That's the problem that this draft was written specifically to address. I like what's happening so far.

>The second use case is to allow a client which is configuring addresses
>for multiple interfaces, or for interfaces other than the one which it
>is using to reach the server, to identify those interfaces.  As I note
>above, we _do_ use hardware addresses for interface identification, and
>to me this is definitely a valid use case.  Here, the option performs a
>function not available in DHCPv4, and is needed only when the client is
>using a feature of DHCPv6 that is also not available in DHCPv4.  The
>need exists whether or not there is a relay involved, and a relay does
>not have enough information to help anyway.

IMO, this is out of scope for this work. This is a different problem space and should likely have a different mechanism to fix it. Whereas the former problem statement is (pretty) clearly defined and understood, and can be fairly easily implemented since many operators/admins have a good amount of control over their relays and servers, very few operators/admins have a functional relationship with DHCP client implementors enough to make the changes being discussed here in the latter use case a reality. I'm not saying it's not a valid use case - I'm saying I don't think it fits the problem this draft was intended to solve, which is a way for operators to tie v4 and v6 endpoints together. Perhaps I'm mistaken, but it seems like this should be pursued as a separate draft.

--Marc