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

[Eric Luehrsen]

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.

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.
>> 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.

- Eric