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

From: "Marc Perea" <[email-masked]>
Date: Wed, 11 Jul 2012 10:20:47 -0500

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

---

From: Simon Hobson <[email-masked]>
Date: Wed, 11 Jul 2012 21:03:34 +0100

A. Gregory Rabil wrote:

>Another aspect of the option not being inserted by the client is 
>that it forces implementations (relays and servers) to read layer 2 
>information from the incoming packets. If the client provides this 
>information as an option, it works for all implementations without 
>such a requirement.

This has also been discussed before.
In an ideal world, we could just change the required client behaviour 
and all the vendors would update their clients and their users would 
update their software/firmware. Meanwhile, back in the real world, 
the opportunity to change clients has (largely) past - but there are 
fewer vendors of servers and relay agents which makes it a better bet 
to do this in the server or relay agent.

If ISC, Dibbler?, Cisco, and a handful of others update their 
server/relay agents, then that's probably the majority of situations 
covered where this is an issue. Plus, you can run a relay agent on 
something other than your routers - so even if your router vendor 
doesn't update, you can just fire up some small Linux/BSD/whatever 
box (can be a virtual machine) on the remote network and you're 
sorted.

In a way it's a parallel argument to using LL (MAC) addresses anyway. 
Again, in an ideal world the specs would have been updated to mandate 
a globally unique client ID, printed on the outside of the box 
(probably with a barcode as well), and sent by both the IPv4 and IPv6 
DHCP clients. Short of inventing a time machine and going back a 
decade or two, that's not going to happen.
So back in the real world again, at least in the IPv4 world we are 
stuck using LL addresses since they are the nearest thing we have to 
a universally present, globally unique, and immutable identifier.
-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.