Re: [rtcweb] Transports: RFC 4941 support?

Dan Wing <dwing@cisco.com> Thu, 20 March 2014 17:08 UTC

Return-Path: <dwing@cisco.com>
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 291801A0785 for <rtcweb@ietfa.amsl.com>; Thu, 20 Mar 2014 10:08:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.047
X-Spam-Level:
X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 si3pszPaRt_A for <rtcweb@ietfa.amsl.com>; Thu, 20 Mar 2014 10:08:08 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5515D1A03BF for <rtcweb@ietf.org>; Thu, 20 Mar 2014 10:08:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6182; q=dns/txt; s=iport; t=1395335279; x=1396544879; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=9UATpVjrvIl3cNfG5rOeMHDIke7DVvhdWaYKkGQJbEw=; b=kMZYuX844x1ac7iLXaTlfnPFHDPPAzJhKdoLjSBR2WJCFw/TcykfZNx6 1bVZ/4cH7l6xFyI1MSbDvXnVlrMki+YMRMFdkr2FJvZVsbwi8F0pAD232 lhjEle7xppnch7VUEG4WHponHsRVGM3yj00TY5pDENSuSjBqZaRDDh9/x 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AisFAIgfK1OrRDoI/2dsb2JhbABZgkJEw2GBGRZ0giUBAQEEeRALDgouVwYTh3jPcReOZQeDJIEUBIlSiwmDbJIwg00dgSwk
X-IronPort-AV: E=Sophos; i="4.97,695,1389744000"; d="scan'208,217"; a="105328425"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 20 Mar 2014 17:07:59 +0000
Received: from sjc-vpn3-1362.cisco.com (sjc-vpn3-1362.cisco.com [10.21.69.82]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2KH77Pv017753; Thu, 20 Mar 2014 17:07:58 GMT
Content-Type: multipart/alternative; boundary="Apple-Mail=_1B3B2EBA-B610-4FDC-8B23-6B54AB78DAC9"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <CAOJ7v-0Dx4Owam7NzXqs6ALPi+ps9gKbmFK9=Zu5eBr9yHYgKg@mail.gmail.com>
Date: Thu, 20 Mar 2014 10:07:58 -0700
Message-Id: <444DE75E-BF07-4C6F-91B1-CF57DC67FBA3@cisco.com>
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> <5329B617.2070001@alvestrand.no> <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> <CAOJ7v-0Dx4Owam7NzXqs6ALPi+ps9gKbmFK9=Zu5eBr9yHYgKg@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5TWbslruwP6v-bQkFf_bQCCg20U
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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: Thu, 20 Mar 2014 17:08:10 -0000

On Mar 20, 2014, at 9:34 AM, Justin Uberti <juberti@google.com> wrote:

> 
> 
> 
> On Thu, Mar 20, 2014 at 7:52 AM, Dan Wing <dwing@cisco.com> wrote:
> 
> 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]."
> ?
> 
> I think it needs to be stronger than that - something like 
> "where host and network policy permit, RTCWEB implementations SHOULD gather IPv6 temporary addresses and SHOULD NOT gather non-temporary addresses".
> 
> Preferring to use temporary addresses is probably not sufficient to prevent linkage, since you will have connectivity checks from the non-temporary addresses. (i.e. an eavesdropper listening over an extended period of time could determine calls are from the same endpoint)

Agreed.  I like your suggested wording.

-d