Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01

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

My point here is that if non-relayed environments are out of scope, that
should be clearly specified in the draft.  The abstract and problem
description does not say anything about it applying only to relayed
environments.

As for the specification not defining the implementation, I agree.
 However, it seems that the nature of this option indeed _forces_ the
implementation.

Greg

On Thu, Aug 16, 2012 at 1:37 PM, Chuck Anderson <[e-mail]> wrote:

> On Thu, Aug 16, 2012 at 12:56:05PM -0400, A. Gregory Rabil wrote:
> > While I am generally in support of this draft, I have previously
> expressed
> > that I believe that there are some clear benefits to having the client
> send
> > its link layer address instead of the relay.  I completely understand
> that
> > from a deployment standpoint, it is much easier to upgrade relays and
> > servers than to wait for clients to implement a new option.
> >
> > In any case, I believe this draft should clarify some items.  For
> example,
> >
> > 1. As it stands, the draft talks only about networks where a relay agent
> is
> > used.  The draft should specify the expected behavior for networks
> without
> > a relay.
>
> I disagree.  This draft is only about a relay option.  There is no
> change to servers or clients with this draft, except that a server may
> use the additional information in the RELAY-FORW message.
>
> > 2. Since the option will only appear in RELAY_FORWARD messages, what is
> the
> > expected behavior for requests that are not forwarded by a relay? Are
> there
> > any implications to the fact that the information will not be in every
> > packet that the server receives from the client?
>
> There is no required behavior change for clients or servers specified
> in this draft, therefore what you ask is out of scope.  This is no
> different than Option82 in DHCPv4--if the information is missing or
> the packet wasn't relayed, then the server can't use it to classify
> clients.
>
> > 3. In section 4, how is the relay agent expected to obtain the client's
> > link-layer address?  Is the relay agent code required to be implemented
> at
> > layer 2?  Could it, for example, determine the LL address by
> > reverse-engineering the client's EUI-64 link-local IPv6 address?
>
> I could go along with additional text in Section 4 to specify that the
> Relay Agent should insert the LL address of the IPv6 interface that is
> being configured on the client.  How an implementation does that is an
> implementation detail and doesn't need to be specified here, but I
> don't think EUI-64 can be relied upon to contain the proper client LL
> address in all cases.
>
> > 4. If there is no relay, is the DHCPv6 server expected or required to
> > obtain this information itself?  If so, the same questions regarding the
> > layer-2 implementation requirements are probably applicable.
>
> No, that functionality is out of scope for this draft.  A server could
> extract a LL address in the same way that a relay would, but that
> behavior isn't specified.
>
> I don't think we should block this draft in order to extend it to
> specify how the server may acquire a client's LL address other than
> via a RELAY-FORW message.  For the intended use cases as described in
> Section 2, an operator can easily design their network to be sure that
> all DHCPv6 traffic passes through a relay.  For the non-relayed case,
> it would be much easier to modify an open source DHCPv6 server to
> implement whatever behavior is wanted without affecting other parts of
> the network--hence there is less need to standardize that behavior
> through the IETF.  The Relay Agent option described in this draft does
> benefit from standardization since an agreed format for passing the
> information from the Relay to the Server will need to be implemented
> by many switch/router vendors as well as server software vendors.
>
> If it is desired to specify additional client and/or server behavior
> for other use cases such as non-relayed packets, I would prefer that
> it be done in separate draft(s).
>