Hi Eric, 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? 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
