> Op 12 mrt. 2017, om 18:31 heeft Eric Luehrsen <ericluehr...@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@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
