Tommy,

On 07/24/2018 02:21 AM, Tommy Pauly 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?

I think that there are three key issues here:

1) Discussion of tradeoffs
2) Specification of mechanisms that allow us to convey different policies
3) Selection of e.g. defaults/desired actions


First step is #1, which is what we did in one of our IDs, and of course
needs more work. This helps us understand the implications f each of the
possible options, and maybe decide what to expose in #2, and e.g. what
the defaults should be for #3 -- and maybe even rule out some cases.

That's what at least I'd suggest that we start with #1
(draft-gont-taps-address-usage-problem-statement &
draft-gont-taps-address-analysis).

In many cases, there are tradeoffs. So one should provide the mechanisms
that allow apps/OSes t make the tradeoffs. But everything starts with
understanding the problem, and understanding the tradeoffs.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Reply via email to