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

[Jeffrey Hutzelman <[e-mail]>]

On Tue, 2012-07-10 at 14:11 +0000, Ted Lemon wrote:
> On Jul 9, 2012, at 7:41 PM, A. Gregory Rabil wrote:
> > I don't believe the information would be the same in the case where
> > the client is requesting an address for a different interface (which
> > is possible in DHCPv6, but not in DHCPv4).  That's what I was trying
> > to explain with the rest of my post.
> 
> Why do we care?   The link layer address is not an interface
> identifier—it's a hint to be used by your corporate back-office
> inventory tracking system so that it can tell that an IPv4 address
> belongs to the same machine as an IPv6 address.

No.  Not only is it an interface identifier; for this purpose, it is
_the_ interface identifier.  We use client hardware addresses not just
for after-the-fact tracking, but for making decisions about what
addresses to assign, what options to send, and what DDNS updates to do,
among other things.

It seems to me there are two use cases here, which argue for different
uses of the option:


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.

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.


I would suggest that for the first use case, the option be added at the
top-level by the relay agent.  Relays which support this option should,
in the normal case, unconditionally add or replace this option at the
top level.  Clients SHOULD NOT use this option at the top level.

For the second use case, a client wishing to identify a particular
interface may do so by using this option in the IA options field for
that interface.  Relays SHOULD NOT add, modify, or remove this option at
the IA level.

-- Jeff