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