Subject: Re: Better APIs (was: Re: Address privacy)

From: Michael Richardson <[email-masked]>
Date: Sat, 01 Feb 2020 14:19:58 +0100

Fernando Gont <[email-masked]> wrote:
    >> 
    > [..]
    >> 
    >> I think that we should not oversell the benefits, but that doesn't
    >> mean there are none. (I think that the benefits have been oversold
    >> within the IETF)
    >> 
    >> I'd like to see 6man look to better APIs for address selection.

    > Good grief. We did this:
    > https://tools.ietf.org/id/draft-gont-6man-address-usage-recommendations-04.txt

You did that, but as you say:

    > I presented it once in 6man, and was suggested it belonged elsewhere. I
    > tried elsewhere (taps), but it seems they believe it belonged
    > elsewhere.

*6man* hasn't gone there.
It can't advance without feedback and support from running code.
(OS vendors)

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 2 Feb 2020 08:13:24 +1300

> It can't advance without feedback and support from running code.

And draft-ietf-v6ops-ula-usage-considerations which Fernando's draft
mentions hasn't gone anywhere either. And in terms of POSIX, RFC3542
hasn't gone anywhere since *2003*.

If we sit back and do nothing, the socket API will never properly support
the richness of IPv6.

   Brian

---

From: Tommy Pauly <[email-masked]>
Date: Sat, 01 Feb 2020 13:23:18 -0800

Hi Fernando,

For the record, the TAPS documents have indeed incorporated API recommendations to support this in the current working version of the draft:

https://ietf-tapswg.github.io/api-drafts/draft-ietf-taps-interface.html#name-local-address-preference <https://ietf-tapswg.github.io/api-drafts/draft-ietf-taps-interface.html#name-local-address-preference>

5.2.12. Local Address Preference
Name:
local-address-preference
Type:
Enumeration
This property specifies whether Listeners and Connections should prefer the use of temporary addresses when possible. This is generally used to prevent linking connections over time when a stable address is not needed. Possible values are:

Stable:
Prefer the use of stable (sometimes called "permanent") local addresses
Temporary:
Prefer the use of temporary (sometimes called "privacy") addresses [RFC4941]
The default is to prefer the use of stable local addresses for Listeners and Rendezvous Connections, and to prefer the use of temporary addresses for other Connections.

Thanks,
Tommy

> On Jan 30, 2020, at 10:20 AM, Fernando Gont <[email-masked]> wrote:
> 
> On 30/1/20 11:12, Michael Richardson wrote:
> [..]
>> I think that we should not oversell the benefits, but that doesn't mean there
>> are none. (I think that the benefits have been oversold within the IETF)
> Good grief. We did this: https://tools.ietf.org/id/draft-gont-6man-address-usage-recommendations-04.txt
> 
> This work would have lead to the *real* issues for which some are blaming temporary addresses in this thread.
> 
> I presented it once in 6man, and was suggested it belonged elsewhere. I tried elsewhere (taps), but it seems they believe it belonged elsewhere.
> 
> So I guess the problem we are dealing with with be solved by someone, somewhere (someday? :-) ).
> 
> Thanks,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: [email-masked]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Erik Kline <[email-masked]>
Date: Sat, 1 Feb 2020 13:33:24 -0800

On Sat, Feb 1, 2020 at 1:23 PM Tommy Pauly <tpauly=
[email-masked]> wrote:

> Hi Fernando,
>
> For the record, the TAPS documents have indeed incorporated API
> recommendations to support this in the current working version of the draft:
>
>
> https://ietf-tapswg.github.io/api-drafts/draft-ietf-taps-interface.html#name-local-address-preference
> <https://ietf-tapswg.github.io/api-drafts/draft-ietf-taps-interface..html#name-local-address-preference>
>
> This property specifies whether Listeners and Connections should prefer
> the use of temporary addresses when possible. This is generally used to
> prevent linking connections over time when a stable address is not needed.
> Possible values are:
>
> Stable:
> The default is to prefer the use of stable local addresses for Listeners
> and Rendezvous Connections, and to prefer the use of temporary addresses
> for other Connections.
>
>
This makes sense to me.  +1

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 3 Feb 2020 09:13:27 +0900

On Fri, Jan 31, 2020 at 4:14 AM Michael Richardson <[email-masked]>
wrote:

> So, I have an FTP control channel open for two weeks.
> I want to bind a new socket for data tranfers... and now I can't bind the
> IP
> address that I want.  Okay, FTP is ancient dead.  Replace with SIP.
> Yes, HTTP/2 and/or QUIC knows how to do this easier.
> I don't know that I want to force everything to convert to QUIC.
>

This has never worked with 4941 because the longest-lived address expired
after one week, i.e., one week before you attempted to bind the socket.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 6 Feb 2020 19:35:30 -0300

On 1/2/20 18:23, Tommy Pauly wrote:
>     This property specifies whether Listeners and Connections should
>     prefer the use of temporary addresses when possible. This is
>     generally used to prevent linking connections over time when a
>     stable address is not needed. Possible values are:
> 
>     Stable:
>     The default is to prefer the use of stable local addresses for
>     Listeners and Rendezvous Connections, and to prefer the use of
>     temporary addresses for other Connections.

This is good, but only scratches the surface. See requirements on on
address scopes, bind()ing addresses, etc.

Thanks,