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

perl-list <perl-list@network1.net> Thu, 12 July 2012 15:11 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 4C0A221F87CC for <dhcwg@ietfa.amsl.com>; Thu, 12 Jul 2012 08:11:28 -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 1eVIa7wH8ZLd for <dhcwg@ietfa.amsl.com>; Thu, 12 Jul 2012 08:11:22 -0700 (PDT)
Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2D83B21F87BA for <dhcwg@ietf.org>; Thu, 12 Jul 2012 08:11:22 -0700 (PDT)
Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id 980425410E0; Thu, 12 Jul 2012 11:11:52 -0400 (EDT)
Date: Thu, 12 Jul 2012 11:11:52 -0400
From: perl-list <perl-list@network1.net>
To: Andre Kostur <akostur@incognito.com>
Message-ID: <1879457686.30777.1342105912528.JavaMail.root@network1.net>
In-Reply-To: <CAL10_BqMRGRJhg_nO-8F4GQxZMJusGu9w2Sfg_OWmabBDQm4MA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_30776_366693047.1342105912527"
X-Originating-IP: [74.115.182.5]
X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC20 (Mac)/7.2.0_GA_2669)
Cc: dhcwg@ietf.org, Ted Lemon <Ted.Lemon@nominum.com>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.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: Thu, 12 Jul 2012 15:11:28 -0000

This is done with ISPs in mind. ISPs typically use the mac address to maintain customer records as it is the most consistent method of identifying a device on an IPv4 / DHCPv4 network. RRAS or other router types internal interfaces are typically ignored in the IPv4 space and are privately addressed from the customer perspective. Hence, the ISP neither needs nor wants knowledge of those interfaces. In the IPv6 / DHCPv6 world, one would assume that the PD to the internal interfaces would need to be correlated with the external / WAN interface of the customer equipment. The mac address of the WAN can serve the needs here too. 
----- Original Message -----

> From: "Andre Kostur" <akostur@incognito.com>
> To: "perl-list" <perl-list@network1.net>
> Cc: "A. Gregory Rabil" <greg.rabil@jagornet.com>, dhcwg@ietf.org,
> "Ted Lemon" <Ted.Lemon@nominum.com>
> Sent: Thursday, July 12, 2012 10:18:08 AM
> Subject: Re: [dhcwg] I-D Action:
> draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt

> On Thu, Jul 12, 2012 at 5:57 AM, perl-list <perl-list@network1.net>
> wrote:

> > Also, as
> > this draft is intended to help correlation between DHCPv4 and
> > DHCPv6 using
> > the (hardware / link layer / MAC - whatever we are calling it these
> > days)
> > address, your argument about downstream interfaces that would not
> > be known
> > in DHCPv4 space is irrelevant.

> Changing gears for a second... if the point behind this draft is to
> correlate DHCPv4 and DHCPv6 leases, is the MAC address sufficient?
> Consider the case of any device using the DHCPv4 client identifier to
> distinguish between multiple leases on the same computer. (One client
> that I know does this is Microsoft RRAS servers.). Or any case where
> there is no MAC address to speak of (wasn't there something like DHCP
> over Infiniband which mandated the use of Client ID since there was
> no
> MAC address?).

> Or are we writing these cases as "we don't care about these edge
> problems, using the MAC address will solve the vast majority of the
> cases"?

> --
> Andre Kostur