Re: [dhcwg] Stephen Farrell's Discuss on draft-ietf-dhc-dynamic-shared-v4allocation-07: (with DISCUSS and COMMENT)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 28 May 2015 11:52 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1C91A1AB2; Thu, 28 May 2015 04:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkW12hKhAGaz; Thu, 28 May 2015 04:52:28 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EC011A0406; Thu, 28 May 2015 04:52:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CE2B5BF02; Thu, 28 May 2015 12:52:25 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiK1mnt6ku31; Thu, 28 May 2015 12:52:25 +0100 (IST)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 96B21BF01; Thu, 28 May 2015 12:52:25 +0100 (IST)
Message-ID: <55670179.8030400@cs.tcd.ie>
Date: Thu, 28 May 2015 12:52:25 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "Bernie Volz (volz)" <volz@cisco.com>
References: <20150526122630.11294.73575.idtracker@ietfa.amsl.com> <273F8D1F-1674-425D-B455-AD0980D13552@gmail.com> <5565D571.7000607@cs.tcd.ie> <B678DDFC-AB66-4B05-BE77-7FCE08CB6748@nominum.com>, <5566FA8D.5050305@cs.tcd.ie> <85BBF76A-257E-407D-844D-748874CDC340@cisco.com> <55670042.1090700@cs.tcd.ie> <489D13FBFA9B3E41812EA89F188F018E1CAF5DA3@xmb-rcd-x04.cisco.com>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1CAF5DA3@xmb-rcd-x04.cisco.com>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/n4CQnQSypMz52-lpGsU7A1LconM>
Cc: "<draft-ietf-dhc-dynamic-shared-v4allocation.shepherd@ietf.org>" <draft-ietf-dhc-dynamic-shared-v4allocation.shepherd@ietf.org>, "<dhc-chairs@ietf.org>" <dhc-chairs@ietf.org>, "<draft-ietf-dhc-dynamic-shared-v4allocation@ietf.org>" <draft-ietf-dhc-dynamic-shared-v4allocation@ietf.org>, The IESG <iesg@ietf.org>, "<dhcwg@ietf.org>" <dhcwg@ietf.org>, "<draft-ietf-dhc-dynamic-shared-v4allocation.ad@ietf.org>" <draft-ietf-dhc-dynamic-shared-v4allocation.ad@ietf.org>, Ted Lemon <Ted.Lemon@nominum.com>
Subject: Re: [dhcwg] Stephen Farrell's Discuss on draft-ietf-dhc-dynamic-shared-v4allocation-07: (with DISCUSS and COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
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, 28 May 2015 11:52:29 -0000


On 28/05/15 12:49, Bernie Volz (volz) wrote:
> The client always most identify itself consistently in all packets sent by the client to the server - and for DHCP that is again either by mac-address or client-identifier option.
> 
> I do not think it appropriate to change how DHCP works in this document.

So that confuses me. If the above is an inherent necessity for dhcp
then why does the current document need a 2119 MUST?

S.

> 
> - Bernie
> 
> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] 
> Sent: Thursday, May 28, 2015 7:47 AM
> To: Bernie Volz (volz)
> Cc: Ted Lemon; Qi Sun; <draft-ietf-dhc-dynamic-shared-v4allocation.ad@ietf.org>; <dhc-chairs@ietf.org>; <draft-ietf-dhc-dynamic-shared-v4allocation@ietf.org>; The IESG; <dhcwg@ietf.org>; <draft-ietf-dhc-dynamic-shared-v4allocation.shepherd@ietf.org>
> Subject: Re: [dhcwg] Stephen Farrell's Discuss on draft-ietf-dhc-dynamic-shared-v4allocation-07: (with DISCUSS and COMMENT)
> 
> 
> 
> On 28/05/15 12:33, Bernie Volz (volz) wrote:
>> There is no PSID at the start of client allocation request
>> (DHCPDISCOVER)
> 
> Maybe I'm mis reading the draft but I thought it was saying client identifier was a MUST in all cases, and not only for DHCPDISCOVER.
> 
> If it said client identifier was needed in case <foo> but otherwise could be omitted (assuming that works) then I think that'd be better.
> 
>> and client id is from the client to the server in DHCP. DHCP client 
>> identity is based on mac-address (already explained why not 
>> appropriate) or client id option. Why would we want to change this?
> 
> I'm not suggesting a change like that, but only to omit the identifying information when that's possible.
> 
> S
> 
>>
>> - Bernie
>>
>>> On May 28, 2015, at 7:22 AM, Stephen Farrell 
>>> <stephen.farrell@cs.tcd.ie> wrote:
>>>
>>>
>>> Hi Ted,
>>>
>>>> On 27/05/15 20:16, Ted Lemon wrote: On May 27, 2015, at 10:32 AM, 
>>>> Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>>>>> I don't believe I saw an answer to the question above. What is the 
>>>>> answer? (I think that is the key thing in figuring out how to 
>>>>> handle the discuss btw.)
>>>>
>>>> The base protocol specification uses either the client identifier 
>>>> option or the client MAC address as an identifier.
>>>> This document is requiring the use of the client identifier option, 
>>>> and excludes the use of the MAC address, which potentially increases 
>>>> user privacy in the event that the DHCP
>>>> privacy profile is used.   If the specification allowed the
>>>> client to use its MAC address alone as an identifier, this would not 
>>>> be possible.
>>>>
>>>> However, I think the actual reason that the client identifier is 
>>>> being required here is that the specific interface that is being 
>>>> configured on the client is not a hardware interface--it's a virtual 
>>>> point-to-point link, which has no hardware address, and thus the 
>>>> client identifier is the only possible identifier to use.
>>>
>>> But isn't the PSID here exactly the idenfier needed (plus the address 
>>> where one's been allocated)?
>>>
>>> S.
>>>
>>>>
>>>> The client identifier or MAC address is used as a database key by 
>>>> the DHCP server to track resources allocated to the client: in
>>>> this case the A+P port set.   Without such a key, there would be
>>>> no way to renew the client's lease on that particular A+P port set, 
>>>> and so TCP connections would be broken each time the client's lease 
>>>> expired.
>>>>