Re: [rtcweb] Transports: RFC 4941 support?

Harald Alvestrand <harald@alvestrand.no> Wed, 19 March 2014 15:22 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD011A0778 for <rtcweb@ietfa.amsl.com>; Wed, 19 Mar 2014 08:22:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.446
X-Spam-Level:
X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQfIolINglPS for <rtcweb@ietfa.amsl.com>; Wed, 19 Mar 2014 08:22:10 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC781A03FF for <rtcweb@ietf.org>; Wed, 19 Mar 2014 08:22:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id D6D6E7C4E21 for <rtcweb@ietf.org>; Wed, 19 Mar 2014 16:22:00 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uy9LZ5Ivnxh2 for <rtcweb@ietf.org>; Wed, 19 Mar 2014 16:21:59 +0100 (CET)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 937A47C4DE1 for <rtcweb@ietf.org>; Wed, 19 Mar 2014 16:21:59 +0100 (CET)
Message-ID: <5329B617.2070001@alvestrand.no>
Date: Wed, 19 Mar 2014 16:21:59 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CAOJ7v-0Hw0NFs_avsB2Z8do21BCws2LRZSeSh6HP0t455SPXyw@mail.gmail.com> <B6836FFA-867A-4CBF-9855-D265425EC5E1@cisco.com> <CAOqqYVE=i2L7FxGgKuV0DVaaxYOPnxzSEbDoq0_4Tqapna575g@mail.gmail.com> <CD747481-EBDA-4FFC-A31D-618E6E217420@cisco.com>
In-Reply-To: <CD747481-EBDA-4FFC-A31D-618E6E217420@cisco.com>
Content-Type: multipart/alternative; boundary="------------050300090907080509030004"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xsHVQIzvP32Xiu4HP4m2fB7uODY
Subject: Re: [rtcweb] Transports: RFC 4941 support?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Mar 2014 15:22:19 -0000

On 03/19/2014 04:08 PM, Dan Wing wrote:
>
> On Mar 19, 2014, at 12:02 AM, Harald Alvestrand <hta@google.com 
> <mailto: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 
>> <mailto:dwing@cisco.com>> wrote:
>>
>>
>>     On Mar 18, 2014, at 6:00 PM, Justin Uberti <juberti@google.com
>>     <mailto: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