Re: [rtcweb] Transports: RFC 4941 support?

[Justin Uberti <[e-mail]>]

On Thu, Mar 20, 2014 at 7:52 AM, Dan Wing <[e-mail]> wrote:

>
> On Mar 19, 2014, at 8:21 AM, Harald Alvestrand <[e-mail]>
> wrote:
>
> On 03/19/2014 04:08 PM, Dan Wing wrote:
>
>
> On Mar 19, 2014, at 12:02 AM, Harald Alvestrand <[e-mail]> wrote:
>
> I'd like to be silent on the issue, since which IPv6 addresses to prefer
> is likely to be a matter of system policy. Trying to override system policy
> in an application specific profile usually leads to sadness.
>
>
> The application needs to indicate if it wants a temporary address. If the
> host's policy (or configuration or network) does not support temporary
> addresses, the application won't get a temporary address.  I don't see why
> being silent helps?
>
>
> What API is it using?
>
> With a little Googling, the system policy I was thinking of was the policy
> in RFC 6724 ("Default Address Selection for IPv6"), in particular section 5
> rule 7: "Prefer  temporary addresses".
>
> I'm happy to say "it is a good idea for systems to implement the
> recommendations of RFC 6724" (or some more 2119-like language). I wouldn't
> want to claim that if a system has chosen to prefer non-temporary
> addresses, it would have to change its non-conformance to RFC 6724 in order
> to be conformant with RTCWEB specifications.
>
>
> So perhaps:
>    "An RTCWEB implementation SHOULD prefer to use temporary addresses
> [RFC4941] where host and network policy permit [RFC6724]."
> ?
>

I think it needs to be stronger than that - something like
"where host and network policy permit, RTCWEB implementations SHOULD gather
IPv6 temporary addresses and SHOULD NOT gather non-temporary addresses".

Preferring to use temporary addresses is probably not sufficient to prevent
linkage, since you will have connectivity checks from the non-temporary
addresses. (i.e. an eavesdropper listening over an extended period of time
could determine calls are from the same endpoint)