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

[Paul Oranje]

> Op 12 mrt. 2017, om 18:31 heeft Eric Luehrsen <ericluehrsen at hotmail.com> het volgende geschreven:
> 
> 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.
What policies the server could implement while serving a requested IA_TA ? (In case the server has to deal with a (rare) client that does requests that).
I ask this question since the nature of this IA probably restricts what policies one can implement.

> 
> 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.
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev