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
