Re: [rtcweb] Transports: RFC 4941 support?

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

So perhaps:
   "An RTCWEB implementation SHOULD prefer to use temporary addresses [RFC4941] where host and network policy permit [RFC6724]."
?

-d

> 
>> 
>> -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 list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb