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

perl-list <perl-list@network1.net> Tue, 14 August 2012 16:54 UTC

Return-Path: <dankney@network1.net>
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 C8BF321F87A0 for <dhcwg@ietfa.amsl.com>; Tue, 14 Aug 2012 09:54:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdKtPtMmWho2 for <dhcwg@ietfa.amsl.com>; Tue, 14 Aug 2012 09:54:47 -0700 (PDT)
Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 08BB221F879F for <dhcwg@ietf.org>; Tue, 14 Aug 2012 09:54:46 -0700 (PDT)
Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id 27E3E541107 for <dhcwg@ietf.org>; Tue, 14 Aug 2012 12:54:46 -0400 (EDT)
Date: Tue, 14 Aug 2012 12:54:46 -0400
From: perl-list <perl-list@network1.net>
To: dhcwg@ietf.org
Message-ID: <1042177688.120003.1344963286073.JavaMail.root@network1.net>
In-Reply-To: <CAL10_BppEa6q648F1m0FddMoxgg9nAR+M0VhvrwnT3MS=WZDXw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_120002_1250578011.1344963286072"
X-Originating-IP: [74.115.182.5]
X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC21 (Mac)/7.2.0_GA_2669)
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01.txt
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: Tue, 14 Aug 2012 16:54:47 -0000

paragraph 1 is fine in my opinion as it does provide some background regarding how things were done. 

Also - it might be important to note in paragraph 2 that without the link layer address, there is no global way to identify DHCPv4 and DHCPv6 allocations to the same hardware as the IDs are not compatible. A lthough I have seen an RFC somewhere about making the IDs from DHCPv6 used in DHCPv4, it is unlikely that this will happen on any wide scale. It is also possible, in some cases, but not all, to extract the hardware address from the DUID (depending on what method of generation was used). Perhaps some of this logic should be added to the draft as further evidence for the need of this option? 

I don't know - the way it reads now, it sounds like it is just there to help people who haven't implemented some other available tracking method. The reality is that there isn't a reliable alternative to correlate between DHCPv4 and DHCPv6. 
----- Original Message -----

> From: "Andre Kostur" <akostur@incognito.com>
> To: dhcwg@ietf.org
> Sent: Tuesday, August 14, 2012 11:10:36 AM
> Subject: Re: [dhcwg] I-D Action:
> draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01.txt

> On Mon, Aug 13, 2012 at 7:33 PM, <internet-drafts@ietf.org> wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Dynamic Host Configuration Working
> > Group
> > of the IETF.
> >
> > Title : Client Link-layer Address Option in DHCPv6
> > Author(s) : Gaurav Halwasia
> > Shwetha Bhandari
> > Wojciech Dec
> > Filename :
> > draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01.txt
> > Pages : 6
> > Date : 2012-08-13

> I think section 2, paragraph 1 is somewhat superfluous (does it
> really
> matter how DHCPv4 carries the link-layer address, or merely that it
> does carry it in every packet?). I think that it would be clearer to
> start with paragraph 2, talking about how we wish to associate a
> DHCPv6 lease with a DHCPv4 lease instead of focusing on the
> link-layer
> address first, then talking about why it's a problem.

> --
> Andre Kostur
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg