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

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

What does not satisfy about that first sentence is that it limits the
usefulness of this option because of the part that says "the interface on
which the packet was originally sent".  My argument is that although this
may be useful, it it not a complete solution because I would like it to
identify the interface which is being configured.

This text is from the section 2 of the draft:

   In dual stack scenarios it is desirable for the operator
   to associate DHCPv4 and DHCPv6 messages as belonging to the same
   client interface based on an identifier that is already used by that
   operator such as the client hardware address.


This refers to the client interface, not just the client.  This statement
is reiterated by the author earlier in this email thread:

> Since one of the uses of learning link layer address was to correlate
DHCPv4 and DHCPv6 messages from the same client interface ( as described
in Section 2 Problem Background and Scenario of the draft), the link layer
address should match 'chaddr' field of DHCPv4 messages sent for
configuring the same interface.

I believe I have explained how this may not always be the case if the relay
is responsible for inserting the option, whereas it can be ensured if the
client does it.

As an example, consider a client which is dual-stacked on two interfaces.
 In DHCPv4, each request MUST be sent with a chaddr of the interface being
configured, which is, by definition, the interface on which the request is
sent.  In this situation, an administrator could provide different options,
etc. for each interface based upon what the back-office database says.  In
DHCPv6, the text in RFC 3315 section 16 suggests that it is possible for
the client to send a request out an interface other than the one being
configured.  In this scenario, it may not be possible to correlate this as
being "messages from the same client interface" as the DHCPv4 client.
 Earlier you referenced and "inventory tracking system has a list of all
the interfaces on a machine".  What if that inventory tracking system is
trying to "discover" the interfaces by reading the DHCP server's lease
database?  DHCPv4 cannot correlate the two interfaces to being on the same
client, so even if it is the same server serving all four requests (v4 and
v6 address for each interface), it is possible that both v6 requests look
to be coming from one interface.  So, an inventory system would learn that
one interface has an IPv4 address and two IPv6 addresses, and the other
interface has one IPv4 address, which would be incorrect.

In the end, I think it comes down to the fact that DHCPv4/v6 configure
interfaces, not machines.  Administrators are accustomed to being able to
configure interfaces (not machines) by their link-layer address in DHCPv4.
 I believe that in order to provide this same capability in DHCPv6, we need
to ensure that the option identifies the interface being configured, not
just the machine.

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.

Greg



On Tue, Jul 10, 2012 at 11:53 PM, Ted Lemon <[e-mail]> wrote:

>  On Jul 10, 2012, at 11:30 PM, A. Gregory Rabil wrote:
>
> I believe this is exactly what limits the usefulness of this option.  Why
> not identify the machine AND the interface?  I understand the argument that
> it is easier to update relay agents versus clients, but it just seems like
> this is incomplete solution.  I also understand the DUID/IAID and am not
> out to change that at all.  I would simply like add this link-layer option
> to identify the interface actually being configured in order to provide as
> much information as possible for administrative control, because experience
> has shown that such controls are inevitably needed.
>
>
>  The purpose of the draft was very simply and exclusively to tag each
> DHCPv6 packet with the link-layer address of the interface on which the
> packet was originally sent.   This is a very simple, very restricted scope.
>   It's something that I think everyone in the working group can agree on.
> It's also very easy to implement, because it can be done in the relay agent.
>
>  What you've said is very difficult for me to parse—you seem to be
> imputing a ton of additional protocol and semantic detail on top of
> something very simple.   Can you state in simple, clear terms why the first
> sentence in the paragraph above does not satisfy you?
>
>