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

["Bernie Volz (volz)" <[e-mail]>]

It needs a MUST because the DHCP protocol (RFC 2131/2132) specifies that the client-identifier option is OPTIONAL. If not present, the mac-address is used. And as has already been discussed, the mac-address is not a good choice here because of the tunnel interface.

Thus, this document REQUIRES that the client use the client-identifier option when using shared-v4-allocation requests - the option is not optional.

- Bernie
 
-----Original Message-----
From: Stephen Farrell [mailto:[e-mail]] 
Sent: Thursday, May 28, 2015 7:52 AM
To: Bernie Volz (volz)
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>; <[e-mail]>; Qi Sun; The IESG; <[e-mail]>; Ted Lemon
Subject: Re: [dhcwg] Stephen Farrell's Discuss on draft-ietf-dhc-dynamic-shared-v4allocation-07: (with DISCUSS and COMMENT)



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:[e-mail]]
> Sent: Thursday, May 28, 2015 7:47 AM
> To: Bernie Volz (volz)
> Cc: Ted Lemon; Qi Sun; 
> <[e-mail]>; 
> <[e-mail]>; 
> <[e-mail]>; The IESG; 
> <[e-mail]>; 
> <[e-mail]>
> 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 
>>> <[e-mail]> wrote:
>>>
>>>
>>> Hi Ted,
>>>
>>>> On 27/05/15 20:16, Ted Lemon wrote: On May 27, 2015, at 10:32 AM, 
>>>> Stephen Farrell <[e-mail]> 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.
>>>>