Re: [dhcwg] DUID+IAID

[Ted Lemon <[e-mail]>]

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

Because it is not an identifier.   It is a hint.   If you call it an identifier, someone will start using it as one.

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

In principle there's nothing incorrect about this statement, but in practice there is no protocol need to identify the interface.   So if you call it an identifier, people are going to confuse it with the DHCPv4 way of identifying *clients*, and not understand that you mean it to be identifying *interfaces*.   So it's better to not put it that way.

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

This is a use case that was advocated at the time RFC3315 was written, but I didn't understand at the time under what circumstances this would happen, and as the protocol has evolved, I think it's pretty clear that it isn't a plausible use case.   If you want to configure an interface, you send a DHCP packet on that interface, not on some other interface.

It's possible that you might want to use DHCP to allocate an address for a tunnel endpoint, but in that case there is no physical interface, and the MAC address that the relay agent will add to the packet will be the address of the physical interface, not the tunnel, which has no MAC address.   So this is another reason not to call this an "interface identifier."   It's the MAC address of the interface out which the DHCP packet was sent.