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

From: Tim Chown <[email-masked]>
Date: Sun, 1 Apr 2018 09:12:02 +0000

> On 31 Mar 2018, at 00:57, Fernando Gont <[email-masked]> wrote:
> 
> On 03/29/2018 12:23 PM, Tim Chown wrote:
> [....]
>> 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?
> 
> Well, this talks about *support* of RFC4941. There's still the question
> of whether such support should be enabled by default or not?

RFC 6724 rule 7 says prefer temporary addresses, albeit with some accompanying words on when it makes sense to do otherwise, but that's the default.

>> (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?
> 
> Or just RFC7217.

Not if the admin wants to admin stuff with ACL control and be a regular browsing / application user elsewhere?

>> 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.
> 
> FWIW, what we posted on TAPS is essentially some flavor of
> draft-gont-6man-address-usage-recommendations

Which is a good starting point.

Tim

> Thanks!
> 
> Cheers,
> -- 
> Fernando Gont
> e-mail: [email-masked] || [email-masked]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
>

---

From: Erik Kline <[email-masked]>
Date: Thu, 5 Apr 2018 16:37:58 -0700

On 29 March 2018 at 13:05, Brian E Carpenter
<[email-masked]> wrote:
> On 29/03/2018 13:20, Fernando Gont wrote:
>> On 03/27/2018 08:10 PM, Brian E Carpenter wrote:
>>>>     > FWIW, this has been the whole point of:
>>>> I think that we need to extend the IPv6 APIs so that applications
>>>> can either request stable addresses or demand a new privacy address.
>>>
>>> Yes. But unfortunately that's outside the scope of the IETF, since we gave
>>> away that API many years ago. I guess we could write a draft and find out
>>> how to get it into the POSIX process.
>>
>> I think there's a difference between an abstract API (that is certainly
>> within the scope of the IETF), and a concrete API (say, for different
>> OSes or languages), which are not.
>
> True. But in real life, we aren't going to revolutionize the basic design
> of the IPv6 socket API, so any new abstractions have to be mappable into
> the POSIX model.

True.

One thing that could have been done back in getaddrinfo days would
have been to recommend the existence of some async version.  That's
not necessarily easy in C, but nevertheless.

I started to collect some thoughts about a v6 addrs abstract API, but
only got as far as this half-baked document:

    https://github.com/ekline/draft-v6addrs-api/blob/master/draft.txt

I think it's probably possible to implement something as a library for
Linux, that would include a thread that listens on a netlink socket
for changes in addresses.

After I get out from under some more pressing work I'm hoping to back
to thinking about it more.