Re: [rtcweb] Transports: RFC 4941 support?

[Harald Alvestrand <[e-mail]>]

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.



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