[simon_vetter]

Work is in progress to make webrtc implementations work over ipv6 but it's not ready yet. Chrome 34 will implement it behind a feature flag (googIPv6:true) [1], and hopefully Firefox will follow suit.

When they do, most pain points caused by NATs will go away, and that's not webrtc specific. While you'll always encounter some (intentionally?) broken network which only allows 80/tcp and 443/tcp from time to time, there's not much you can do about it, and webrtc can't do much about it.

[1] http://code.google.com/p/webrtc/issues/detail?id=1406

[jmspring]

> When they do, most pain points caused by NATs will go away, and that's not webrtc specific.

This is a naive statement since it assumes IPv6 support amongst the clients. At least here in the US, such support is fairly minuscule.

[ay]

In the US, today, one in 15 clients accessing google.com / yahoo.com / facebook.com is doing it from an IPv6 address.

And it's more than double compared to a year ago [1].

While indeed this still qualifies as "relatively small", I think it grew out of the "miniscule" :-)

[1] http://6lab.cisco.com/stats/cible.php?country=US

[jmspring]

I think mobile operators are going to drive the near term biggest uptick in ipv6 adoption.

My local ISP (small, independent) has no current IPV6 plans, which is actually a little bit annoying.

[AshleysBrain]

Thanks for the heads up, this does look like it will help a lot! (Assuming IPv6 reaches most people eventually)