On Sat, Oct 17, 2009 at 09:31:56AM -0400, Bernie Volz (volz) wrote:
> You might want to look at what Cablelabs did with DOCSIS 3.0 ... in
> particular the Cablelabs device identifier vendor-specific option. This
> works because there is a single mac-address for the CM and the CMTS
> (relay) can insert this data in the flow between client and server
> (whether client here is CM or CPE).
> 
> See
> http://www.cablelabs.com/specifications/CL-SP-CANN-DHCP-Reg-I03-090811.p
> df, section 5.2.15 Device Identifier Option.

Ah, I'd forgotten about that.

I've been given a patch that implements something similar in ISC DHCP,
and I am inclined to integrate it (probably not in 4.2.0a1, but soon
after) with some minor cosmetic changes; basically this would use
ISC's Vendor Specific Information Option, and would work in the same
way (the MAC address is inserted by ISC's relay agent).

With two competing ad-hoc vendor implementations it sounds like we
really should be looking at a standard, core solution to these
problems.

> At the time Cablelabs was working on this, we were discussing a "device
> identifier" option that would be a standard DHC WG (IETF/IANA) assigned
> option to provide a device identifier (most likely a mac-address, but it
> was to be defined to support other identifiers) but it wasn't clear how
> this would be used and how it would handle situations such as the case
> of a device with multiple interfaces and hence multiple device
> identifiers. One possibility is that as DHCPv6 requests would occur on
> each interface separately, the Client Identifier (DUID) would contain
> the same identifier for all requests but this "device identifier" would
> specify that interface's mac-address. The DHCPv6 server could then use
> the two values in different ways.

I would characterize DHCPv6's deficit here in the IAID.  It
is supposed to discriminate the specific interface inside the DHCPv6
client, but it fails to provide meaningful interface identity.  It
would have been better, for IPv4->IPv6 migration, if the IA's were
identified by MAC address rather than IAID, but alas, and you'd still
have to describe an IAID analogue for those networks that don't have
MAC layer addressing at all.

This is for example the reason why I used the last 4 octets of the
interface's MAC address as the IAID in ISC's DHCPv6 client (and I've
observed others that also do this).  It's handily simple for me, and
at least this information is of some use to the server operator, even
if at 4 octets it can't be comfortably guaranteed unique it is at
least anecdotal in packet dumps.

I guess my point is I would look within the IA_*'s for solutions,
maybe extending IA's with an interface-info option.

My own personal preference as a sometimes-network-operator would be
for clients to advertise an "IA Name", similarly in function to a
"desired hostname."  This would have two divisions inside it; the
interface's "local name" in whatever local OS parlance, and the
hardware address.  Either may be empty, of obviously the option may be
omitted, but it is useful for a client to advertise this information.
I haven't decided if more verbose interface information
(speed/duplex/more) should be included.

I also plan to do something like this in the client in an ISC VSIO
option, which is not a universal solution but at least the ISC client
would provide server administrators with sufficient information even
where an ISC (or DOCSIS) relay wasn't in use.

Of course even with a standard option it would slowly find its way in
client implementations, so in the meantime a migration tool is needed,
and I think that's where the relay agent method comes in.

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/