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

[Eric Luehrsen]

This discussion has really put some requirements and restrictions on 
what I am trying to implement. I like that. Excuse my stream of 
consciousness writing style, if you question "what? .. crazy?" then its 
likely my fault for not editing well.

On 03/11/2017 11:39 AM, Paul Oranje wrote:
>> RFC 3315 section 22.5:
>>
>>    An IA_TA option does not include values for T1 and T2.....
> The use-case that Eric gave as an example - as I understood it - concerns policies that are enforced at the server side; at the client site “management" cannot enforce anything.
>
Simply, a rational management desire would be to have similar or 
"transparent" system of policies between IP4 and IP6. They have decades 
of "Oh! ####!" lessons learned including tools built around DHCPv4. They 
want evolution not revolution in the change over.

During an hypothetical IP6 roll out plan meeting ... The potential for 
IP6 to profile a network externally is considered and the emotional 
response is "unsettling" at best. The potential for loss of control with 
SLAAC is equally emotional. Hopefully someone well spoken and well 
respected explains NAT is not security, or storm clouds form.

Desire: one global IP6 per (virtual) machine just like was had with IP4.
Desire: external network obscurity just like was had with IP4.
Desire: full traceability and accountability for all intranet and 
internet connections.
Desire: time and point of first connection logs as mobile devices attach.
Desire: not require extra steps or tools for general employees to "work 
around" issues.
Desire: IT policy/training/manuals don't need to change in grand 
structure  (only change specifics in implementation)
Desire: DUID or Client-ID or MAC is an "asset tag" and not modified 
session to session.

DHCPv6 IA_NA which is NOT simply a fixed hash of DUID but also a random 
function over moderate periods of time would be within standard and meet 
these desires. Within "accountability and traceability" a limit to 
address roll over frequency creates another rational definition of 
"non-temporary."

>> In any case, there are existing client implementations of IA_TA (for
>> example ISC dhclient and dibbler) and RFC7721 stable IIDs (for example
>> Linux kernel and NetworkManager).
> Maybe you can create a patch that would implement IA_TA in odhcpd, if that isn’t implemented yet (I do not know, have a look at the code).
> That would satisfy another use case.
This could/should also be done, but many as-purchased devices just don't 
handle IA_TA (well). Okay, more generically IP6 isn't often handled 
(well). It will be hard to test robustly. IA_TA can deliver a plurality 
of addresses for machine/connection obscurity. "How many?" becomes a 
compatibility and complexity issue as one example.

Hurdle: If IT is conservative about in house modification and wants to 
deploy user-end equipment as-purchased, then this could limit their 
supplier options and the buyers negotiation leverage. Modifying and 
maintaining infrastructure is an IT job. Supporting all the daily user 
issues is often part of the service contract with the user equipment 
provider. If we want providers support, then use the equipment 
as-purchased or within boundaries as specified in the contract.