Re: [rtcweb] Transports: RFC 4941 support?

(and, to be clear, that by default, non-temporary addresses SHOULD NOT be
used by clients)

On Wed, Mar 19, 2014 at 9:08 AM, Justin Uberti <juberti@google.com> wrote:

> 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:
>
>>  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
>>
>>
>