Subject: rfc4941bis: trying to keep focus

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jan 2020 17:50:45 -0300

Folks,

I'm trying to summarize what I've seen as part of the recent discussion 
about (or at least triggered by) rfc4941bis.

First, let me give the (obvious) context:

rfc4941bis is meant, for the most part, to address flaws in RFC4941 --
RFC4941 is a Standards Track document, already. rfc4941bis is not 
proposing or introducing temporary addresses, but simply addressing 
flows in the scheme *we already have* (which is widely deployed).

Now, let's move to the main topics of this discussion:

1) "temporary addresses results in too many addresses"

This is not a problem araising from RFC4941, but a problem with SLAAC. 
In SLAAC, routers offer network configuration information, and hosts 
do... what they virtually please.

Routers could also advertise many different prefixes on the same link, 
leading to many addresses. Hosts could also manually configure lots of 
addresses.  An OS might also provide a proprietary interface for 
proprietary apps to request "one address per flow".

Given a sufficient number of prefixes and hosts, this may get to a point 
where implementation limits such as the maximum number of NCE may be hit.

If folks are concerned about the maximum number of addresses that may be 
employed in a network (a valid concern), then I guess energy should be 
spent on how to address this general issue of SLAAC, *in SLAAC*, as 
opposed to simply bother about one of the many possible ways in which a 
host may configure addresses.

I'd note that we have a BCP (RFC7934) about the topic of "number of 
addresses". In the typical/default case, RFC4941 will lead to a maximum 
of 7 addresses per host. In the context of RFC7934, I guess being able 
to handle 7 addresses per host is the least one could expect. I do 
understand that some systems can't handle them (given a sufficient 
number of hosts). Maybe we need to send a signal to router vendors. 
Maybe a few thousand entries in the NC is way too IPv4ish? All these 
issues are worth discussing... but they are issues with SLAAC or ipv6 
network configuration, and not with RFC4941.

That said, and given recent feedback, it seems sensible to reduce the 
preferred lifetime and valid lifetime of temporary addresses to 1 day 
and 2 days, respectively. This would result in one preferred and one 
deprecated temporary addresses (as opposed to 1 preferred and 6 
deprecated addresses resulting from RFC4941).

2) The value of temporary addresses

As noted above, one would assume that since RFC4941 has not been 
deprecated, there is consensus that RFC4941 provides value in the area 
of privacy.

Everytime you reuse an identifier, it leaks information. Temporary 
addresses reduce the address lifetime, and hence limit the amount of 
time you reuse an identifier. That's an improvement. And it is a 
middleground between not using temporary addresses (and hence resuse the 
same identifier forever) or doing "one address per flow" which, while 
interesting, would take the number of addresses employed in any network 
to another dimension. As such (a middle-ground), it can't be expected to 
be perfect.

Temporary addresses are meant employed for outgoing connections. Maybe 
RFC4941 should provide stronger hints or even recommendations that this 
use mode is enforced. For connection-oriented transport protocols, the 
concept is straightforward. For stateless protocols, not so much.

But even if this mode is enforced for connection-oriented transport 
protocols, this would make temporary addresses reduce host exposure 
quite a lot. This is another area where temporary addresses have value.

That said, I'm not sure to what extent it makes sense to argue about the 
value of temporary addresses in the context of *this* document. If we 
take the to extreme possible outcomes:

* we don't publish rfc4941bis, and we keep a flawed RFC4941
* we publish rfc4941bis, and have an improved version of rfc4941

Only one of these options will improve RFC4941, and none of them will 
obsolete rfc4941.

3) Should temporary addresses be enabled by default?

One would assume that since RFC4941 has not been deprecated, there is 
consensus that RFC4941 provides value in the area of privacy.

In that sense, and in the context of RFC7258, I believe it would be a 
hard case to make to have temporary addresses disabled by default.

I do believe some network might want to disable them. That would require 
the network to be able to convey this policy to hosts. This was tried 
(draft-gont-6man-managing-slaac-policy) and rejected ten years ago.

I believe that, at least in the absence of policy, and in the context of 
RFC7258, it is sensible for the default to be "on".

Besides, in a post-Snowden era, I believe we'd nevertheless have a hard 
time recommending OS vendors to disable them by default.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 31 Jan 2020 07:46:47 +0000

Hello Fernando 

Long but great summary !

Please see below 

> Le 30 janv. 2020 à 21:52, Fernando Gont <[email-masked]> a écrit :
> 
> Folks,
> 
> I'm trying to summarize what I've seen as part of the recent discussion about (or at least triggered by) rfc4941bis.
> 
> RFC4941 is a Standards Track document, already. rfc4941bis is not proposing or introducing temporary addresses, but simply addressing flows in the scheme *we already have* (which is widely deployed).
> 
> 
> This is not a problem araising from RFC4941, but a problem with SLAAC. In SLAAC, routers offer network configuration information, and hosts do... what they virtually please.
> 

And they don’t express their intention and/or ask if it’s ok.

> Routers could also advertise many different prefixes on the same link, leading to many addresses. Hosts could also manually configure lots of addresses.  An OS might also provide a proprietary interface for proprietary apps to request "one address per flow".
> 
> Given a sufficient number of prefixes and hosts, this may get to a point where implementation limits such as the maximum number of NCE may be hit.
> 

NCE in the host is hardly a limit as it was in the last century when ND was designed. The problem has migrated to harder state in the network that cannot be easily removed and reformed for the lack of cooperation.

I still agree with your bottom line.

> If folks are concerned about the maximum number of addresses that may be employed in a network (a valid concern), then I guess energy should be spent on how to address this general issue of SLAAC, *in SLAAC*, as opposed to simply bother about one of the many possible ways in which a host may configure addresses.

I’d say this general issue of SLAAC, *in IPv6ND*. The SL may partially need to go away. Because it’s been a lie for roughly 10 years already in managed networks. But we can maintain the AAC whenever it’s valuable.

> 
> I'd note that we have a BCP (RFC7934) about the topic of "number of addresses". In the typical/default case, RFC4941 will lead to a maximum of 7 addresses per host. In the context of RFC7934, I guess being able to handle 7 addresses per host is the least one could expect. I do understand that some systems can't handle them (given a sufficient number of hosts). Maybe we need to send a signal to router vendors. Maybe a few thousand entries in the NC is way too IPv4ish? All these issues are worth discussing... but they are issues with SLAAC or ipv6 network configuration, and not with RFC4941.
> 

Yes.

 What would enrich 4941 would be improved signaling by the router In RA messages of the constraints it wants applied. Once we have that the default does not really matter any more.

The other thing that would improve the draft is a bit in the NA signaling whether the address is permanent or transient.

I can propose text if you like.

But the real thing is to rethink AAC. Which took 10 years in the IOT world but was finally published.

> That said, and given recent feedback, it seems sensible to reduce the preferred lifetime and valid lifetime of temporary addresses to 1 day and 2 days, respectively. This would result in one preferred and one deprecated temporary addresses (as opposed to 1 preferred and 6 deprecated addresses resulting from RFC4941).
> 

There is a confusion between the valid lifetime of the prefix and that of an address. We should be able to revalidate an address within the prefix lifetime. I agree with Michael, losing sessions (VNC in my case) is embarrassing and a loss of perceived quality vs. IPv4.

> As noted above, one would assume that since RFC4941 has not been deprecated, there is consensus that RFC4941 provides value in the area of privacy.
> 
> Everytime you reuse an identifier, it leaks information. Temporary addresses reduce the address lifetime, and hence limit the amount of time you reuse an identifier. That's an improvement. And it is a middleground between not using temporary addresses (and hence resuse the same identifier forever) or doing "one address per flow" which, while interesting, would take the number of addresses employed in any network to another dimension. As such (a middle-ground), it can't be expected to be perfect.
> 
> Temporary addresses are meant employed for outgoing connections. Maybe RFC4941 should provide stronger hints or even recommendations that this use mode is enforced. For connection-oriented transport protocols, the concept is straightforward. For stateless protocols, not so much.
> 
> But even if this mode is enforced for connection-oriented transport protocols, this would make temporary addresses reduce host exposure quite a lot. This is another area where temporary addresses have value.
> 
> That said, I'm not sure to what extent it makes sense to argue about the value of temporary addresses in the context of *this* document. If we take the to extreme possible outcomes:
> 
> Only one of these options will improve RFC4941, and none of them will obsolete rfc4941.
> 

Choose your evil?

> One would assume that since RFC4941 has not been deprecated, there is consensus that RFC4941 provides value in the area of privacy.
> 
> In that sense, and in the context of RFC7258, I believe it would be a hard case to make to have temporary addresses disabled by default.
> 
> I do believe some network might want to disable them. That would require the network to be able to convey this policy to hosts. This was tried (draft-gont-6man-managing-slaac-policy) and rejected ten years ago.
> 

Things change. People awareness improves. 

> I believe that, at least in the absence of policy, and in the context of RFC7258, it is sensible for the default to be "on".
> 
> Besides, in a post-Snowden era, I believe we'd nevertheless have a hard time recommending OS vendors to disable them by default.
> 

The problem is not there anyway. The problem is to get to a point where the hosts and network agree on the addresses, and that can happen with many addresses if that’s what serves the user best.

A side thing is to admit that SLAAC is obsolete in a number of environments, and damaging to the network operation. But as you say it’s about modernizing ND not counting addresses.

All the best,

Pascal 

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 31 Jan 2020 17:43:38 +0900

Fernando,

I agree with all your points. I don't think it's a good idea to pause or
derail this update because of more general concerns that some participants
have with temporary addresses in general or with SLAAC in general.
Temporary addresses have been extremely widely deployed for many years, and
it seems unlikely that we would degrade them to historic, or that
implementers would stop implementing them. If there are bugs in RFC 4941
that impact user privacy, and we can fix them, then we should absolutely do
so, and do so sooner rather than later.

Cheers,
Lorenzo