Re: [rtcweb] Transports: RFC 4941 support?

ICE by default is going to gather host candidates from all interfaces,
which means that the non-temporary addresses are going to be used,
regardless of priority, for connectivity checks at least.

As a result, if we don't do anything, it means 2x the v6 interfaces, and 4x
the v6-v6 ICE checks, in addition to any linkability concerns.

We could say that if a system has chosen to prefer non-temporary-addresses,
or privacy is not a concern, then non-temporary-addresses can be used.

On Wed, Mar 19, 2014 at 8:21 AM, Harald Alvestrand <harald@alvestrand.no>wrote;wrote:

>  On 03/19/2014 04:08 PM, Dan Wing wrote:
>
>
>  On Mar 19, 2014, at 12:02 AM, Harald Alvestrand <hta@google.com> 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.
>
>
>  -d
>
>
>
>
>
> On Wed, Mar 19, 2014 at 6:14 AM, Dan Wing <dwing@cisco.com> wrote:
>
>>
>>  On Mar 18, 2014, at 6:00 PM, Justin Uberti <juberti@google.com> wrote:
>>
>>  https://tools.ietf.org/html/rfc4941 defines the concept of temporary
>> IPv6 addresses. For, example, as enumerated on my local system:
>>
>>  inet 172.31.x.y netmask 0xfffffe00 broadcast 172.31.x.255
>> inet6 2620::1008:100b:e2f8:47ff:wwww:xxxx prefixlen 64 autoconf
>> inet6 2620::1008:100b:819e:1d3f:yyyy:zzzz prefixlen 64 autoconf
>> *temporary *
>>
>>  As indicated in the RFC, the temporary addresses expire after hours or
>> days, and therefore could be used to prevent long-term linkability of
>> sessions. Expiration shouldn't be an issue for WebRTC, since we can simply
>> do ICE restart if this occurs during a session.
>>
>>  Is this something we want to recommend in the transports doc?
>>
>>
>>   Yes.
>>
>>  And it should be as frequent as every new 'call', if IPv6 privacy
>> addresses are to provide the same privacy as a NAPT44, as a NAPT44 should
>> be assigning random ports per reasons described in RFC6056.
>>
>>  The transport document should also recommend doing port randomization
>> (RFC6056), as that was found pretty useful for DNS, but randomizing ports
>> is still not popular with many OS's TCP stacks for whatever reason.
>>
>>  -d
>>
>>
>>
>
>
>
> _______________________________________________
> rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>