Re: [dhcwg] DUID+IAID

["A. Gregory Rabil" <[e-mail]>]

> In practice there's no difference.   But it doesn't identify the
interface.
> It provides additional information about the interface that can be used
as a database key to associate devices to the DUID.

I am not sure I understand that.  Why would the proposed
hardware-addr-option not identify the interface?

In DHCPv4, we only know the interface identifier (chaddr), we can't really
identify the device itself.  That is, we can't correlate multiple
interfaces to the same device without resorting to something less than
ideal, such as the hostname.  In DHCPv6 (as it stands now), we can identify
the device (DUID), but not the interface.  My understanding of the proposal
is that the MAC address is *added* to the request as an option, so we would
have both the DUID and the MAC, thus allowing us to identify both the
device and the interface, which is good IMO.

>The problem we are trying to solve is twofold.   First, tying the mac
address on a shipping box to a device making a query on the network using
>DUID.   Second, tying the chaddr field from a DHCPv4 message to the DUID
of a DHCPv6 message.   So consider the CPE router--it's sending >its DHCPv4
packet on the upstream interface, and it's sending its DHCPv6 packet on the
upstream interface.   In both cases, the hardware >address we want to send
is the hardware address of the upstream interface.   It makes no sense to
send the hardware address of any of the >downstream interfaces.

Yes, I believe I understand this use case, and I agree that my example with
the downstream interface may not have been a good choice.  However,
consider a more complicated example where a device has multiple upstream
interfaces.  As I read that snippet from RFC 3315, such a device may send
multiple IAs in one request where, for example, one IA_NA is for upstream
interface A, and a second IA_NA is for upstream interface B.  If this is
possible, then I was simply suggesting that the proposed
hardware-addr-option be an IA-level option rather than a message-level
option, so as to identify each interface.

Greg