Re: I-D Action: draft-fgont-6man-rfc4941bis-01.txt

[Tim Chown <[e-mail]>]

> On 27 Mar 2018, at 20:40, Brian E Carpenter <[e-mail]> wrote:
> 
> On 27/03/2018 21:35, Fernando Gont wrote:
>> On 03/26/2018 11:52 PM, Brian E Carpenter wrote:
>>>>> 
>>>>>> 6. Temporary addresses are *not* disabled by default.
>>>>> 
>>>>> Specifically, this text was removed:
>>>>> 
>>>>>> Consequently, the use of temporary addresses SHOULD be disabled by	
>>>>>> default in order to minimize potential disruptions.
>>>>> 
>>>>> My concern is that the disruptions ("some applications may not behave
>>>>> robustly if temporary addresses are used") haven't gone away, and the
>>>>> cause may be very hard for ordinary users to diagnose. In fact, I
>>>>> think some of the cases of help desks advising users to switch off
>>>>> IPv6 derive from recently shipped operating systems that enable
>>>>> temporary addresses by default. I've disabled them on a couple of
>>>>> Windows 10 laptops for this reason.
>>>> 
>>>> Through what impact of using privacy addresses?  What are the problematic applications?
>>> 
>>> I don't know what the 4941 authors were thinking of. 
>> 
>> I guess they were referring to long-lived connections?
> 
> Probably. What I'm complaining about is services that have some
> sort of reputation system based on individual /128s. Temporary
> addresses do create a behaviour pattern that doesn't exist for
> IPv4 clients.
> 
>>> The example
>>> I've seen is mentioned below: a service that considers frequent
>>> changes of IP address to be a sign of illicit activity.
>> 
>> This is tricky already, anyway. With happy-eyeballs sort of behavior,
>> this can already happen (one connection happens over v4, and a
>> subsequent happens over v6).
>> 
>> I do believe that, for all such cases, giving apps more control (and
>> awareness!) regarding v6 addressing and what they can do about it is
>> needed. But that would be out of cope for this particular document, I think.
>> 
>> That said, we could add a comment about this issue in this document.
>> Thoughts?
> 
> Yes, an explanation of this side-effect issue would help. Also perhaps,
> replace the old "off by default" text by a requirement that it must be
> easy for the user to disable temporary addresses if they cause problems.
> IMHO, netsh interface ipv6 set privacy state=disabled store=persistent
> doesn't count as "easy" for a normal user.

The current 6434-bis says

"RFC 4941 SHOULD be supported.  In some scenarios, such as dedicated
   servers in a data center, it provides limited or no benefit, or may
   complicate network management.  Thus devices implementing this
   specification MUST provide a way for the end user to explicitly
   enable or disable the use of such temporary addresses."

Is that the sort of wording you'd like?

(https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-08#page-15)

> There are real scenarios where "on by default" can be a problem.
> Here are some fragments of the real world:
> http://kb.tableau.com/articles/Issue/identifying-and-disabling-temporary-ipv6-addresses

This one seems largely about using (or not) privacy addresses for servers?

> https://lonesysadmin.net/2018/01/23/disable-windows-ipv6-temporary-addresses/

This is a more pragmatic one, where today ACLs may allow a specific admin's workstation IP access somewhere.
Maybe that's a case for RFC8273, with the ACL on the /64 prefix?  Though if it is an administratively configured system, disabling RFC 4941 should be pretty easy.
Or there are certificate-based solutions, etc.

In general, I agree with Mikael's comment on TAPS, where I think Fernando already has a draft on this topic.

Tim

>   Brian
> 
>> 
>> 
>>> (Remember, my concern is only about the default configuration
>>> and the resulting puzzlement of ordinary users and help desks.)
>> 
>> Another part of the problem here is that you cannot hint the network
>> about what to do. e.g., see draft-gont-6man-managing-slaac-policy
>> 
>> Thanks!
>> 
>> Cheers,
>> 
>