Subject: rfc4941bis: Invalid addresses used by ongoing sessions

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Feb 2020 06:14:10 -0300

Folks,

As currently specified, temporary addresses are removed when they become
invalid (i.e., the Valid Lifetime expires).

Section 6 ("6.  Future Work") of the draft
(https://tools.ietf.org/id/draft-ietf-6man-rfc4941bis-06.txt) still
keeps the following text from RFC4941.

6.  Future Work

   An implementation might want to keep track of which addresses are
   being used by upper layers so as to be able to remove a deprecated
   temporary address from internal data structures once no upper layer
   protocols are using it (but not before).  This is in contrast to
   current approaches where addresses are removed from an interface when
   they become invalid [RFC4862], independent of whether or not upper
   layer protocols are still using them.  For TCP connections, such
   information is available in control blocks.  For UDP-based
   applications, it may be the case that only the applications have
   knowledge about what addresses are actually in use.  Consequently, an
   implementation generally will need to use heuristics in deciding when
   an address is no longer in use.

I wonder if this text should be:

1) moved more into the body of the document and made a "MAY" (which for
TCP is very straightforward),

2) Be left "as is", or,

3) Removed from the document

The implications of #1 above is that it can't prevent long-lived
connections that employ temporary addresses from being torn down, at the
expense of possibly increasing the number of concurrent IPv6 addresses.

Thoughts?

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: Mon, 10 Feb 2020 16:20:35 +0000

Hello Fernando

The existence of the address impacts the application and the network. If the stack decides unilaterally to remove an address, it is impacting both the application and the network. The future work could include an API so that the application and the stack tell each other when an address is no more used or usable. It could also indicate a protocol for the stack to tell the network that an address is released so the network can make room in the NCE (in advance) and reduce the chances of overload.

All the best

Pascal

> -----Original Message-----
> From: ipv6 <[email-masked]> On Behalf Of Fernando Gont
> Sent: lundi 10 février 2020 10:14
> To: [email-masked]
> Subject: rfc4941bis: Invalid addresses used by ongoing sessions
> 
> Folks,
> 
> (https://tools.ietf.org/id/draft-ietf-6man-rfc4941bis-06.txt) still keeps the
> following text from RFC4941.
> 
> 6.  Future Work
> 
> The implications of #1 above is that it can't prevent long-lived connections that
> employ temporary addresses from being torn down, at the expense of possibly
> increasing the number of concurrent IPv6 addresses.
> 
> Thoughts?
> 
> Thanks!
> 
> Cheers,
> --
> Fernando Gont
> SI6 Networks
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Feb 2020 14:20:39 -0300

Hello, Pascal,

Thanks for the input!

Now, back to the original question: Which of the options #1-#3 do you
think we should pursue?

Thanks!

Cheers,
Fernando

---

From: David Farmer <[email-masked]>
Date: Mon, 10 Feb 2020 11:43:32 -0600

I think I prefer #1, #2 is acceptable, and #3 is a bad idea, I think this
issue needs discussion in the document.

Thanks.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 Feb 2020 07:25:30 +1100

> 3) Removed from the document

I generally like the idea, however I think it should be removed at this
stage because of the ambiguity problem.

Just because an address has been used by TCP doesn't mean it isn't
currently or can't in the near future also be used by UDP (or DCCP or
SCTP). Current source address selection doesn't take into account the
transport layer protocol.

If the temporary address mechanism eventually evolved to the point where
there were "TCP only" and "UDP only" (and DCCP, SCTP) pools of temporary
addresses, then this would be possible to reliably implement.

Regards,
Mark.

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 10 Feb 2020 20:47:56 -0500

I prefer #1 as to place into the body of the document.

This is a very important subject as far trade off.

As from an operational impact from an enterprise perspective as the goal is
to have as minimal as possible addresses on the device without impact to
end user experience. So #1 does achieve this objective.

However, the flip side of the double edged sword in achieving the objective
is that long lived connections using temporary address being torn down.

My thoughts on that is for enterprise devices that are not mobile and fixed
connected to the corporate intranet are the ones in secure environments in
many cases are the ones with long lived connections.  For those cases the
operators can disable the temporary address as a solution.

For all mobile user use case enterprise or other personal mobile device use
option #1.

I think in all cases having API’s for the operators to pick which address
to use for source address selection for any arbitrary use case would be the
end goal.

-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 10 Feb 2020 21:12:32 -0500

> expense of possibly increasing the number of concurrent IPv6 addresses.

  Gyan> So for TCP apps it maybe easier to track via active TCB blocks so
those long lived connections could be tracked.  So those long lived TCP
connections would not be impacted and torn down.  Other apps using UDP may
not be as easily tracked and so maybe using the deprecated address, however
due to difficulty of tracking maybe torn down as a side effect of option
#1.

-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 Feb 2020 13:25:39 +1100

> due to difficulty of tracking maybe torn down as a side effect of option

Long lived connections using temporary addresses should not be a
consideration, because long lived connections should not be using temporary
addresses.

"Temporary" and "long lived" (persistent, stable) are opposites that can
never be resolved.

---

From: Tom Herbert <[email-masked]>
Date: Mon, 10 Feb 2020 18:30:32 -1000

> due to difficulty of tracking maybe torn down as a side effect of option

Gyan,

Connected UDP sockets should work like TCP.

For unconnected sockets, the applications respond to whatever address
packets are received from. If the address for a UDP flow changes the
application needs to adjust to the new address. Note this characteristic
already exists, for instance the apparent endpoint of a UDP flow can change
due to NAT state eviction, and application protocols like QUIC handle this
case.

Tom

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Feb 2020 02:11:50 -0300

On 10/2/20 22:47, Gyan Mishra wrote:
> As from an operational impact from an enterprise perspective as the goal 
> is to have as minimal as possible addresses on the device without impact 
> to end user experience. So #1 does achieve this objective.

Actually #1 may do the opposite. If addresses that are being used are 
not eliminated when their Valid Lifetime expire, then, as long as each 
address is employed by a long-lived connection, you could end up piling 
up lots of addresses.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Feb 2020 02:16:25 -0300

On 10/2/20 23:25, Mark Smith wrote:
> 
> 
> On Tue, 11 Feb 2020, 13:13 Gyan Mishra, <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
> 
>     On Mon, Feb 10, 2020 at 11:12 AM Fernando Gont
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         Folks,
> 
>        Gyan> So for TCP apps it maybe easier to track via active TCB
>     blocks so those long lived connections could be tracked.  So those
>     long lived TCP connections would not be impacted and torn down. 
>     Other apps using UDP may not be as easily tracked and so maybe using
>     the deprecated address, however due to difficulty of tracking maybe
>     torn down as a side effect of option #1. 
> 
> 
> 
> consideration, because long lived connections should not be using 
> temporary addresses.
> 

In that case, would you go for #2 above? And, what's your position 
regarding reducing the preferred and valid lifetimes?

Thanks!

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Feb 2020 02:24:51 -0300

On 10/2/20 17:25, Mark Smith wrote:
> 
> 
> On Tue, 11 Feb 2020, 03:12 Fernando Gont, <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Folks,
> 

Note: this is simply an "heuristic"/hack to prevent long-lived 
connections from being torn down. i.e., by default,, they would be torn 
down when the address becomes invalid. This "hack" would avoid such 
scenarios.

> addresses, then this would be possible to reliably implement.

If you don't implement this (which is the status quo), then when the 
address becomes invalid, any long-live TCP sessions using this address 
will be torn down. With this hack, that wouldn't happen. Connectionless 
protocols would remain unaffected.  -- just a clarification, so that 
we're on the same page.

Thanks!

Cheers,

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 11 Feb 2020 01:17:02 -0500

Agreed.  Makes sense.  Thanks

-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 11 Feb 2020 07:53:57 +0000

Hello Fernando;

There is a basic problem in the network probing if an address is still used by a host. Starting day 2, the host using default setting should start using a new address and conserve the older addresses in case there's an active connection. If the network probes the address to figure if it's still there, it actually revives it, meaning that in terms of LRU the old address becomes fresher for all participants, including the stack. 

This is just one of the side effects of not telling the network what's happening. The solution has to be holistic -include all parties, app,  net and stack - and cannot be based on snooping. 

I'd rather leave the text as is (2). It's wishful thinking but at least it's there. I'd prefer to move it to a problem statement or see a  solution draft.

Cheers;

Pascal

> From: Fernando Gont <[email-masked]>
> Sent: lundi 10 février 2020 18:21
> To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
> Subject: Re: rfc4941bis: Invalid addresses used by ongoing sessions
> 
> Hello, Pascal,
> 
> Thanks for the input!
> 
> Now, back to the original question: Which of the options #1-#3 do you think we
> should pursue?
> 
> Thanks!
> 
> Cheers,
> Fernando
> 
> 
> 
> 
> > The existence of the address impacts the application and the network. If the
> stack decides unilaterally to remove an address, it is impacting both the
> application and the network. The future work could include an API so that the
> application and the stack tell each other when an address is no more used or
> usable. It could also indicate a protocol for the stack to tell the network that an
> address is released so the network can make room in the NCE (in advance) and
> reduce the chances of overload.
> >
> > All the best
> >
> > Pascal
> >
> >> As currently specified, temporary addresses are removed when they
> >> become invalid (i.e., the Valid Lifetime expires).
> >>
> >> 1) moved more into the body of the document and made a "MAY" (which
> >> for TCP is very straightforward),
> >>
> >> 2) Be left "as is", or,
> >>
> >> connections that employ temporary addresses from being torn down, at
> >> the expense of possibly increasing the number of concurrent IPv6 addresses.
> >>
> >> Thoughts?
> >>
> >> Thanks!
> >>
> >> Cheers,
> >> --
> >> Fernando Gont
> >> SI6 Networks

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 Feb 2020 20:55:17 +1100

On Tue, 11 Feb 2020 at 16:16, Fernando Gont <[email-masked]> wrote:
> In that case, would you go for #2 above?

Probably #2, although mainly because that text is in RFC 3041 and it
hasn't caused issues since. I'm wondering if all the possible
scenarios and consequences have been thought through though.

> And, what's your position

I'm generally okay with the existing defaults, and would probably only
change them if there is a specific reason to.

If I was choosing the values today, I think I would have chosen 6
hours for the preferred lifetime, and 24 hours for the valid lifetime.

I would consider an application's connection that persists longer than
24 hours to be "long lived", and I don't think the sort of devices
where temporary addresses provide the most privacy value (e.g.
end-user PCs, smartphones etc) are likely to have application
connections that are going to persist for more than or even close to
24 hours. It's unlikely that these devices maintain a connection to
the same network for more than 24 hours e.g. they go to sleep
disconnecting from the network, or get taken somewhere else etc.

Humans have to sleep once every 24 hours, so having a "new identity"
i.e. IID within a prefix each day would sound to me to be a reasonable
default.

The current values are probably quite conservative because of the
context  - these original RFC3041 defaults was IIDs that persisted as
long as the network card's hardware address existed - probably 3 to 5
years typically, although possibly much longer (there's a 20 year old
100Mbps NIC in this 11 year old PC for example!). Reducing the
persistence of a node's interface IID value from many years down to 1
week was a very significant privacy improvement.

TL;DR, leave as they are just because there doesn't seem to be a
strong reason to change them.

Regards,
Mark.

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 11 Feb 2020 13:01:42 -0500

> regarding reducing the preferred and valid lifetimes?

   Gyan>. Yes to #2 and I am in favor of reducing the valid lifetime from 7
to 2 days.  That reduces the number of temporary addresses from 7 to 2.
It’s a win for operators with the reduction in addresses.

As far as the text I would modify or maybe clarify that by tracking the
address used by upper layer protocols the implications of doing so that you
increase the number of deprecated addresses.  By doing so tracking the
addresses, the valid lifetime expire timer is in essence not used and so
long lived connections using deprecated address in theory would never
become invalid and can live indefinitely.

We should some text as to severe consequences of long lived connections
with tracking usage.

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Fernando Gont <[email-masked]>
Date: Thu, 13 Feb 2020 14:02:52 -0300

> There is a basic problem in the network probing if an address is still used by a host. Starting day 2, the host using default setting should start using a new address and conserve the older address…

I see the situation as follows:

Case 1: The address becomes invalid, and is removed by the host

The connection is "torn down" (?) on the local host. A remote host that 
had an ongoing session still tries to use it, until eventually the 
connection times out.

Result: the connection fails, and while the address is probed, the LRU 
timestamps are refreshed.

Case 2: The address becomes invalid, but since there is an ongoing 
session, the address is not removed.

The ongoing session survives, and obviously the LRU timestamps are 
refreshed.

With the current status quo, Case 2 has the benefit the the connections 
is not torn down... and I'm not sure it has many downsides when compared 
to #1.

Of course, I agree that if the host could inform the network that the 
address is gone, then it could prevent the LRU timestamps updates. I 
guess this is what you were referring to?

Thanks,

---

From: Tom Herbert <[email-masked]>
Date: Thu, 13 Feb 2020 11:34:26 -0800

> week was a very significant privacy improvement.

Mark,

Why, exactly, was it a very significant privacy improvement? Again, it
seems like almost all of this discussion is based on an intuition as
that temporary addresses help privacy and that shorter lifetimes
provide better privacy. For instance, a twenty-four hour lifetime
might make sense to be minimally invasive, but what does that mean for
providing privacy? Would an hour lifetime so much better privacy that
the inconvenience of kill existing connections is a reasonable
tradeoff. Conversely, what if there's no significant difference
between 24 hrs. and one week in terms of privacy? Why not make the
default one week and be even less invasive to the user?

Tom