Re: [rtcweb] Transports: RFC 4941 support?

[Dan Wing <[e-mail]>]

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?

-d


> 
> 
> 
> On Wed, Mar 19, 2014 at 6:14 AM, Dan Wing <[e-mail]> wrote:
> 
> On Mar 18, 2014, at 6:00 PM, Justin Uberti <[e-mail]> 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
> 
> 
>