Re: [rtcweb] Transports: RFC 4941 support?

Dan Wing <> Fri, 21 March 2014 00:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EDAF31A077C for <>; Thu, 20 Mar 2014 17:08:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vg8kWv1Ci_zh for <>; Thu, 20 Mar 2014 17:08:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 12DAD1A080B for <>; Thu, 20 Mar 2014 17:08:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2591; q=dns/txt; s=iport; t=1395360491; x=1396570091; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=JTWSRiYgHIzVboju2xBLFQcBFU5jReqN7zdmmeZ/Z/c=; b=kck2NRGEMyrUGnnJ39909orqHj9UxrAHeeRV3ST4f0UHVl4oDhaEinzq Sf7PotgGmlu6mpeisV0uUSAh3lwrLmnxHVszQ2/Nsedfuo00h7HQ6zSr9 rM63dSFw/icUIP5JFQIow+xJYwpAZgMeteG8b4Gq/NVVZ/emkAi0w/MA9 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.97,699,1389744000"; d="scan'208";a="108577786"
Received: from ([]) by with ESMTP; 21 Mar 2014 00:08:10 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s2L089IX016340; Fri, 21 Mar 2014 00:08:09 GMT
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Dan Wing <>
In-Reply-To: <>
Date: Thu, 20 Mar 2014 17:08:08 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: Ted Hardie <>
X-Mailer: Apple Mail (2.1874)
Cc: "" <>
Subject: Re: [rtcweb] Transports: RFC 4941 support?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Mar 2014 00:08:32 -0000

On Mar 20, 2014, at 1:56 PM, Ted Hardie <> wrote:

> On Thu, Mar 20, 2014 at 10:07 AM, Dan Wing <> wrote:
> On Mar 20, 2014, at 9:34 AM, Justin Uberti <> wrote:
>> 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
> So, I note that in this case where a non-temporary IPv6 address is present and  no temporary IPv6 address is present, this appears to push IPv6 out of the gathered list completely.  If I have that right, then my view as an individual is that this is the wrong result.  It will either force the use of IPv4 addresses which are just as linkable as IPv6 non-temporary addresses or rely on NATs to get the non-linkability (and provide us all the other subtle joys of NAT). 
> As a friendly amendment, may I suggest "Where both non-temporary and temporary addresses are present and host and network policy permit, RTCWEB implementations SHOULD gather IPv6 temporary addresses and SHOULD NOT gather non-temporary addresses"?
> I also confess to a suspicion that Harald's view is the most sensible--having a separate policy for this application either won't happen or doesn't make much sense. 

Ok, so preface your suggested sentence with,

  “WebRTC applications are encouraged to follow IPv6 Socket API for Source Address Selection [RFC5014] with regards to IPv6 temporary addresses, specifically <insert your sentence>.”

It’s not that WebRTC is trying to do something unique here — we just want this done, and not just hope an implementor stumbles into the right IETF document explaining temporary IPv6 addresses.


> But if we have one, I'd prefer one that doesn't shove IPv6 out the door completely if the host doesn't use temporary addresses.
> regards,
> Ted