Subject: [rtcweb] Fwd: New Version Notification for draft-ietf-rtcweb-transports-01.txt

From: Harald Alvestrand <[email-masked]>
Date: Tue, 03 Sep 2013 11:53:51 +0200

Since I had so much good feedback on the previous version, I've created 
an update.

There's still a couple of open questions, in particular around support 
of TURN/TLS (TLS for connecting from the client to the TURN server).

I have also said nothing about HTTP proxies - after reading through that 
text in -firewall-, I concluded that we need a protocol specification to 
refer to before we can require clients to connect through HTTP proxies.

The protocol specification MIGHT fit on one page - but then again, it 
might not.

-------- Original Message --------
Subject: 	New Version Notification for draft-ietf-rtcweb-transports-01.txt
Date: 	Tue, 03 Sep 2013 02:40:45 -0700
From: 	[email-masked]
To: 	Harald T. Alvestrand <[email-masked]>, Harald Alvestrand 
<[email-masked]>

A new version of I-D, draft-ietf-rtcweb-transports-01.txt
has been successfully submitted by Harald Alvestrand and posted to the
IETF repository.

Filename:	 draft-ietf-rtcweb-transports
Revision:	 01
Title:		 Transports for RTCWEB
Creation date:	 2013-09-03
Group:		 rtcweb
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-transports-01.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports
Htmlized:        http://tools.ietf.org/html/draft-ietf-rtcweb-transports-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-01

Abstract:
    This document describes the data transport protocols used by RTCWEB,
    including the protocols used for interaction with intermediate boxes
    such as firewalls, relays and NAT boxes.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 9 Sep 2013 16:36:47 +0000

Currently draft-ietf-rtcweb-transports-01 does not say anything about IPV6 which I assume it should. Specifically I am thinking that it needs to state a requirement to support RFC6156 support "Traversal Using Relays around NAT (TURN) Extension for IPv6".

I am not sure how much we need to say about webrtc client procedures around RFC6156 and whether they should be included in the draft-ietf-rtcweb-transport or whether it is something we should add to our nat/firewall draft (draft-hutton-rtcweb-nat-firewall-considerations).  Any opinions on this?

Regards
Andy

---

From: Simon Perreault <[email-masked]>
Date: Mon, 09 Sep 2013 18:44:30 +0200

> Currently draft-ietf-rtcweb-transports-01 does not say anything about IPV6 which I assume it should. Specifically I am thinking that it needs to state a requirement to support RFC6156 support "Trav…

+1

> I am not sure how much we need to say about webrtc client procedures around RFC6156 and whether they should be included in the draft-ietf-rtcweb-transport or whether it is something we should add t…

Something along the lines of "IPv6 allocations MUST be requested even
when the client only has IPv4 connectivity." ?

Simon

---

From: "cb.list6" <[email-masked]>
Date: Mon, 9 Sep 2013 09:50:29 -0700

> I am not sure how much we need to say about webrtc client procedures around RFC6156 and whether they should be included in the draft-ietf-rtcweb-transport or whether it is something we should add t…

+1 on covering IPv6 in the transport draft.

I would specifically state that much of the challenges with NATs are
resolved by preferring IPv6.

I would also cover the use case of using TURN to bridge IPv6-only
clients to communicate with IPv4 clients.

It would also be wise to reference RFC6540 to underscore that IPv6 use
is a BCP of the IETF

CB

> Regards
> Andy
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 9 Sep 2013 10:01:28 -0700

> resolved by preferring IPv6.
 [BA] That isn't what we've seen in practice, since IPv6 addresses (particularly tunnel addresses) may not be routable. So in practice, things seem to work better if IPv4 addresses are preferred and in fact, government profiles such as DISA UCR 2008 require the ability to configure an IPv4 preference.  
> clients to communicate with IPv4 clients.
[BA] Yes, this is an important use case (and one that some ICE implementations don't support very well).  
> is a BCP of the IETF.

---

From: "cb.list6" <[email-masked]>
Date: Mon, 9 Sep 2013 10:25:35 -0700

On Mon, Sep 9, 2013 at 10:01 AM, Bernard Aboba
<[email-masked]> wrote:
> [BA] That isn't what we've seen in practice, since IPv6 addresses
> (particularly tunnel addresses) may not be routable.
> So in practice, things seem to work better if IPv4 addresses are preferred
> and in fact, government profiles such as DISA UCR 2008 require the ability
> to configure an IPv4 preference.
>

Is there a citation for this data point about IPv6 not working as well
in production?  I see the DISA thing as not particularly relevant to
the Internet.  That's one way to run  a private network, with knobs to
adjust.

There used to be an issue with 6to4 and maybe Teredo, but i believe
the data shows that this issue has largely been resolved
http://www.google.com/intl/en/ipv6/statistics.html via host treatment
of those tunnels as well as happy-eyeballs in browsers.

I believe happy-eyeballs / RFC6555 would apply to WebRTC interactions
equally well, since the signalling is over the standard HTTP/HTTPS
calls.

Maybe RFC6555 needs to be mentioned in the transport draft as well
since it can be leveraged to mitigate the use of broken IPv6
connections.

CB

> [BA] Yes, this is an important use case (and one that some ICE
> implementations don't support very well).
>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 9 Sep 2013 10:37:12 -0700

> Is there a citation for this data point about IPv6 not working as well in production? 
[BA] At IETF 87 (and in several meetings prior to that), we have had a discussion within the MMUSIC WG about "Happy Eyeballs for ICE" (draft-reddy-mmusic-ice-happy-eyeballs):http://www.ietf.org/proceedings/87/slides/slides-87-mmusic-0.pdf
> of those tunnels as well as happy-eyeballs in browsers.
[BA] Those statistics do not relate to ICEv6 usage, and in particular, they don't cover the range of behavior that we see in enterprise and carrier networks.  As an example, in deployments we have encountered IPv6 NATs and firewalls with a wide range of behavior, IPv6-only carrier networks where connectivity to IPv4 endpoints is needed, etc.  
> equally well, since the signalling is over the standard HTTP/HTTPS calls.
[BA] RFC 6555 doesn't directly apply to ICE, which is why we've been having a distinct "ICE Happy Eyeballs" discussion.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 12 Sep 2013 12:57:00 -0700

> I am not sure how much we need to say about webrtc client procedures around RFC6156 and whether they should be included in the draft-ietf-rtcweb-transport or whether it is something we should add t…

[BA] Adding it to the NAT/Firewall draft makes the most sense to me.  Among other things, it might provide more of an opportunity to get into some of the "Happy Eyeballs" issues that have come up, such as relative prioritization of IPv4 versus IPv6.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 12 Sep 2013 13:06:23 -0700