On Wed, Jul 25, 2018 at 8:05 AM Tommy Pauly <[email protected]> wrote: > > Yes, I'm inclined to agree—I think that having a unique address per > connection shouldn't be the default; an application could certainly always > set it if it wants to decrease linkability?
Applications should not have to opt-in to better privacy. Decreased linkability should be the default. So if doing this per-connection is shown (not just believed) to be infeasible, then per-application is a reasonable compromise. Best, Chris > Perhaps a default could be something more per-user or per-application. > > Best, > Tommy > > > On Jul 25, 2018, at 7:48 AM, Eric Vyncke (evyncke) > > <[email protected]> wrote: > > > > Being a layer-3 person, I am a (just) little concerned by having one IPv6 > > address per connection as it could put some stress on Neighbor Discovery > > (mcast traffic draining battery, cache space/maintenance) if used by > > default on very short live connections > > > > Just a thought > > > > -éric > > > > On 25/07/2018, 12:02, "Taps on behalf of Tom Jones" <[email protected] > > on behalf of [email protected]> wrote: > > > > On Tue, Jul 24, 2018 at 07:58:27PM -0700, Christopher Wood wrote: > >> On Mon, Jul 23, 2018 at 5:21 PM Tommy Pauly <[email protected]> wrote: > >>> > >>> Picking this thread up again, I would like to see us incorporate IPv6 > >>> address selection into a post-sockets API model. > >>> > >>> Here's a straw man proposal of how we can expose this via the TAPS > >>> Interface: > >>> > >>> - A new property for Local Address Preference, which can be a tuple of: > >>> 1. Stable/Public > >>> 2. Temporary/Private > >>> 3. Unique For Connection > >>> - Listeners would default to (1). Connections would default to (2) > >>> - If you specify (3), the system will try to get an entirely new IPv6 > >>> address that has never been used before > >>> - You can find out the address you used on your Listener/Connection > >>> > >>> This type of API would allow us to add in the functionality Erik had > >>> asked for, to allow a client to be able to request a new address. The > >>> other alternative would be to have some out-of-band API to request a new > >>> API, but I think marking this on a connection is preferable, since it > >>> allows us to enforce this per-path and per-protocol even. > >>> > >>> What do people think? > >> > >> Perhaps unsurprisingly, I am fond of this API. Would it be feasible > >> for connections to default to (3) and fall back to (2) if > >> unsuccessful? > >> > > > > I would like to echo my fondness of the API and the preference for (3) > > falling back to (2) if it is feasible. > > > > - Tom > > > > _______________________________________________ > > Taps mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/taps > > > > > > _______________________________________________ > > Taps mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/taps > _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
