[LEDE-DEV] [PATCH odhcpd] dhcpv6-ia: add option for dhcpv6 privacy address

[Paul Oranje]

Small addition (the following may be non-obvious to those not involved in this discussion).
Just saw that A_TA does not have renewal (T1) or rebinding (T2) fields and for that reason cannot suit a use-case like a IA just for a work shift.
-- 
Paul


> Op 11 mrt. 2017, om 13:21 heeft Paul Oranje <phoranje at gmail.com> het volgende geschreven:
> 
>> 
>> Op 11 mrt. 2017, om 06:09 heeft Eric Luehrsen <ericluehrsen at hotmail.com> het volgende geschreven:
>> 
>> On 03/10/2017 09:09 AM, Bjørn Mork wrote:
>>> Eric Luehrsen <ericluehrsen at hotmail.com> writes:
>>>> It appears many other severs and clients dont implement IA_TA. Its a lost option.
>>> Sure. Very few want this feature. We must however assume that those
>>> who do want it will implement it.
>> We must however assume nothing. We may assume something while patiently 
>> waiting for information so we can progress on an idea.
>>>> It should not break "expectations" as this an central administrative
>>>> option.
>>> A client requesting an IA_NA expects a non-temporary address.
>>> 
>> I hate being "legislative" about engineering, but it looks like this is 
>> headed that way, so I'll bite. First in all engineering requirements you 
>> must define your terms. "non-temporary" does not mean "permanent" and it 
>> appears it is carefully avoided as such. In fact the only implied 
>> definition through the chain of RFC is "non-temporary" is just not the 
>> same as "temporary." "temporary" could be summarized as having the 
>> potential for even per connection or per application duration. With that 
>> "non-temporary" can reasonably be defined by the local site 
>> administration as a work shift (8hrs) or something like that.
> rfc3315#section-12 refers to rfc3041 for the definition of temporary addresses.
> The usage of temporary addresses by rfc3041 (Privacy Extensions for Stateless Address Autoconfiguration in IPv6) seems to imply, a contrario, that non-temporary addresses are _not_ to be used for the privacy purposes.
> Strictly logically this implication is incorrect, but still it very much aligns with understandable and reasonable expectations. Anyway, non-temporary isn’t the same as permanent.
> 
>> This means "non-temporary" is a policy decision by the organization 
>> management ("oh no" software engineers cry, "not management"). If 
>> management wants DHCPv6 to provide a single address per user level 
>> machine, then that's their decision to make. If management wants that 
>> each work day or each work shift enumerates all user level machines 
>> differently, then that's their decision to make.  DHCPv6 IA_NA then is 
>> the one and only address that your issued device gets, and it is 
>> different each work day. Static servers may have predefined host 
>> assignments, which I only mention for completeness.
> 
>>>> If central IT doesnt want user base devices to be permanently reachable
>>>> or traceable, then that is their authority to choose.
>>> Definitely.  They can easily achieve this by not providing any IA_NA
>>> adresses.
>> How is that an answer for above management attempting to implement a 
>> particular policy? DHCPv6 IA_TA is not option for (any?) clients. By 
>> your implied definition, a client device would get also an IA_NA that is 
>> "more lasting." It may try to use it, but management doesn't want that. 
>> DHCPv6 without something else leaves devices easily profiled from 
>> external snooping. It's not MAC but not good either. SLAAC exposes the 
>> MAC publicly. SLAAC+privacy is internally difficult to trace, so likely 
>> fail accountability. SLAAC w/ RA rolling hash isn't any more implemented 
>> than IA_TA.
> (mind you, I am not an expert and the following could be utter nonsense).
> Given these use-cases (IAs per work shift etc), why couldn’t these be fulfilled with IA_TA ?
> Both types of associations are within control of the server and hence of whatever management policy, or would the use of IA_NA be necessitated because clients tend not request these ?
> If so, then use of IA_TA is a client policy, and support of those by the DHCPv6 server would be nice. Where the intended enhancement of privacy is a server policy and the client does not request IA_TA, use of IA_NA for this purpose seems alright since whatever address is provided is within the realm of the server for whatever policy it implements thereby.
> 
>>> 
>>>> But on the flip side, central IT doesnt want the insanity of SLAAC
>>>> Privacy all over their network. Consider a fortune 500 company or
>>>> university with accountibilty and traceability in legal or internal
>>>> policy requirements.
>>>> 
>>>> RFC are so namef for a reason and a good working model can change them.
>>> OK, I think you just explained your level of understanding.  Thanks
>> I'll pretend that it doesn't mean how it reads.
> I’ve read the sentence a few times over and still cannot make out what would be meant be it. Still given the effort made to sensibly discus this subject one would be wise to read it positively.
> (credo: when a positive explanation exists that is as reasonable as any other, pick the positive one)
> 
>> 
>> - Eric
> --
> Paul
> 
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev