Small addition (the following may be non-obvious to those not involved in this
discussion).
Just saw that A_TA does not have renewal (T1) or rebinding (T2) fields and for
that reason cannot suit a use-case like a IA just for a work shift.
--
Paul
> Op 11 mrt. 2017, om 13:21 heeft Paul Oranje <phora...@gmail.com> het volgende
> geschreven:
>
>>
>> Op 11 mrt. 2017, om 06:09 heeft Eric Luehrsen <ericluehr...@hotmail.com> het
>> volgende geschreven:
>>
>> On 03/10/2017 09:09 AM, Bjørn Mork wrote:
>>> Eric Luehrsen <ericluehr...@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.
> rfc3315#section-12 refers to rfc3041 for the definition of temporary
> addresses.
> The usage of temporary addresses by rfc3041 (Privacy Extensions for Stateless
> Address Autoconfiguration in IPv6) seems to imply, a contrario, that
> non-temporary addresses are _not_ to be used for the privacy purposes.
> Strictly logically this implication is incorrect, but still it very much
> aligns with understandable and reasonable expectations. Anyway, non-temporary
> isn’t the same as permanent.
>
>> 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.
> (mind you, I am not an expert and the following could be utter nonsense).
> Given these use-cases (IAs per work shift etc), why couldn’t these be
> fulfilled with IA_TA ?
> Both types of associations are within control of the server and hence of
> whatever management policy, or would the use of IA_NA be necessitated because
> clients tend not request these ?
> If so, then use of IA_TA is a client policy, and support of those by the
> DHCPv6 server would be nice. Where the intended enhancement of privacy is a
> server policy and the client does not request IA_TA, use of IA_NA for this
> purpose seems alright since whatever address is provided is within the realm
> of the server for whatever policy it implements thereby.
>
>>>
>>>> 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.
> I’ve read the sentence a few times over and still cannot make out what would
> be meant be it. Still given the effort made to sensibly discus this subject
> one would be wise to read it positively.
> (credo: when a positive explanation exists that is as reasonable as any
> other, pick the positive one)
>
>>
>> - Eric
> --
> Paul
>
>> _______________________________________________
>> 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
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
