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

"A. Gregory Rabil" <greg.rabil@jagornet.com> Thu, 16 August 2012 16:56 UTC

Return-Path: <greg.rabil@jagornet.com>
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 13F9421F860D for <dhcwg@ietfa.amsl.com>; Thu, 16 Aug 2012 09:56:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.872
X-Spam-Level:
X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 l2l0wrYFWhJz for <dhcwg@ietfa.amsl.com>; Thu, 16 Aug 2012 09:56:07 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E47BB21F85DB for <dhcwg@ietf.org>; Thu, 16 Aug 2012 09:56:06 -0700 (PDT)
Received: by bkty7 with SMTP id y7so1198011bkt.31 for <dhcwg@ietf.org>; Thu, 16 Aug 2012 09:56:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=z3/itUNOBMhpaXH+5RT0BJPTUQ8FPDMqtgVr7eYRuW4=; b=bgcEG8ESmR97vOldvXwDiTu7glO3luwxEmCuMd4g5XfOqc40BuejbbI/djaf0glQCi tDTLLssc394Janugb0eN2RsnMd4pd4EnDba54F2MbgQ4/EbcY0ZICSpDSzmukJpJNS1p uV1lt5EFSKB/6gjYyHFmn6KRCqAYAXHbGtzQ93ncdKim54vEyvH5dVnoWwqJCoIp4W2V oEA1o4kO2PGSIEAclMCuvamypr/QBwkIuKXemeBrSn/HFBuGWUFhlq9KOfeEh7Czl5OZ sYwKmQnUjCkBs9i2NY56+sbLzCOrYTEWjCX0isvEHsawr2ZTAjcuncOwMt0MV23AW4OE JkpA==
MIME-Version: 1.0
Received: by 10.204.5.144 with SMTP id 16mr893055bkv.128.1345136165771; Thu, 16 Aug 2012 09:56:05 -0700 (PDT)
Received: by 10.204.189.6 with HTTP; Thu, 16 Aug 2012 09:56:05 -0700 (PDT)
In-Reply-To: <A87A2CCB-21D2-4437-9021-11013FB8218E@nominum.com>
References: <A87A2CCB-21D2-4437-9021-11013FB8218E@nominum.com>
Date: Thu, 16 Aug 2012 12:56:05 -0400
Message-ID: <CAAed6vtYx4g+C1PAWBFQF1aPAx-=PCE2YREnaNDSMYcgAY69_A@mail.gmail.com>
From: "A. Gregory Rabil" <greg.rabil@jagornet.com>
To: dhc WG <dhcwg@ietf.org>, Ted Lemon <Ted.Lemon@nominum.com>
Content-Type: multipart/alternative; boundary="00151758af6455dbe504c764eb12"
X-Gm-Message-State: ALoCoQlch+7npDhduTr2h1e58FIw+hUlYOQOhTmbnRhRLR8D36Rh/th+V26PICdXW6XlTv091Sv6
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 16:56:08 -0000

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

Regards,
Greg

On Thu, Aug 16, 2012 at 10:09 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

> The authors of this document have requested a working group last call.
> There's already been some good review on the list, but more is always
> welcome.   Please post comments if you have any, and also indicate whether
> you support advancing the draft as written, or oppose doing so.   We will
> evaluate consensus on August 31.
>
> I should point out that despite its title, this document is about the
> relay agent forwarding the client link layer address.   There has been
> discussion on the mailing list about other use cases that involve the
> client sending its own link layer address; while these use cases may be of
> interest to the working group in a later draft, they are out of scope for
> this draft, so please indicate the status of your support for the draft as
> currently scoped.   Once this work is done, if someone wants to take up
> work on a new draft with a wider scope, the working group will consider
> doing so.
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>