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

Chuck Anderson <cra@WPI.EDU> Thu, 16 August 2012 17:37 UTC

Return-Path: <cra@WPI.EDU>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2634E21F860D for <dhcwg@ietfa.amsl.com>; Thu, 16 Aug 2012 10:37:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dFrs0YEYQ+y for <dhcwg@ietfa.amsl.com>; Thu, 16 Aug 2012 10:37:46 -0700 (PDT)
Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1E321F85FF for <dhcwg@ietf.org>; Thu, 16 Aug 2012 10:37:46 -0700 (PDT)
Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q7GHbjWT004257; Thu, 16 Aug 2012 13:37:45 -0400
X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU q7GHbjWT004257
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1345138665; bh=wiBln6P3sm8yz9BWuehgWD4FAFDQzcFt6YGxXf+0+KM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=Ia/xorczDLvUgICgJ4NvvseiryZWr/Zx5qXHGYXkzBnGddNPPeM6pustD20FgzsKk 9yAYQchTU8vSeJ3UofYtRxmthYLRQVEu+9Cty9L6tT9ddUugTkJShd1hhWe0pxqyES CBT/Hft2PuubrSEa4W2/gjdgEK2J906tIv277o5Q=
Received: from SMTP.WPI.EDU (SMTP.WPI.EDU [130.215.36.186]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q7GHbjT7004254; Thu, 16 Aug 2012 13:37:45 -0400
Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by SMTP.WPI.EDU (8.14.4/8.14.4) with ESMTP id q7GHbhRF007539; Thu, 16 Aug 2012 13:37:44 -0400 (envelope-from cra@WPI.EDU)
Received: from angus.ind.WPI.EDU (localhost [127.0.0.1]) by angus.ind.WPI.EDU (8.14.4/8.14.4) with ESMTP id q7GHbh7N026858; Thu, 16 Aug 2012 13:37:43 -0400
Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.4/8.14.4/Submit) id q7GHbgY2026857; Thu, 16 Aug 2012 13:37:42 -0400
X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f
Date: Thu, 16 Aug 2012 13:37:42 -0400
From: Chuck Anderson <cra@WPI.EDU>
To: "A. Gregory Rabil" <greg.rabil@jagornet.com>
Message-ID: <20120816173740.GD4612@angus.ind.WPI.EDU>
Mail-Followup-To: "A. Gregory Rabil" <greg.rabil@jagornet.com>, dhc WG <dhcwg@ietf.org>, Ted Lemon <Ted.Lemon@nominum.com>
References: <A87A2CCB-21D2-4437-9021-11013FB8218E@nominum.com> <CAAed6vtYx4g+C1PAWBFQF1aPAx-=PCE2YREnaNDSMYcgAY69_A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAAed6vtYx4g+C1PAWBFQF1aPAx-=PCE2YREnaNDSMYcgAY69_A@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: dhc WG <dhcwg@ietf.org>, Ted Lemon <Ted.Lemon@nominum.com>
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Aug 2012 17:37:47 -0000

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