Subject: [rtcweb] Constraint to disable IPv6 candidate collection

From: Roman Shpount <[email-masked]>
Date: Tue, 7 Apr 2015 18:28:22 -0400

Hi All,

It is possible to run into interop issues with end-points that support ICE
and DTLS-SRTP but do not support IPv6, such as current versions of Firefox.
Chrome currently offers googIPv6 constraint, which enables or disables IPv6
candidate collection. Unfortunately, this constraint is Chrome specific,
provided via deprecated interface (PeerConnection constructor), and when
this constraint is not set, Chrome collects or does not collect IPv6
candidates pretty much in random. Without setting this constraint, the same
Chrome browser on the same network includes or does not include IPv6
candidates with no identifiable pattern. Because of this, we currently set
googIPv6 constraint to false. Our only other alternative would be to
examine the SDP and remove the IPv6 candidates and replace c= line with
IPv4 address. In anticipation of IPv6 support being enabled by default, and
to avoid SDP mucking, it would be better to define a constraint that can be
used to suppress IPv6 candidate collection, which can be provided via
current constraint interfaces.

_____________
Roman Shpount

---

From: 🔓Dan Wing <[email-masked]>
Date: Tue, 7 Apr 2015 17:30:47 -0700

On 07-Apr-2015 03:28 pm, Roman Shpount <[email-masked]> wrote: 
> It is possible to run into interop issues with end-points that support ICE and DTLS-SRTP but do not support IPv6, such as current versions of Firefox. Chrome currently offers googIPv6 constraint, which enables or disables IPv6 candidate collection. Unfortunately, this constraint is Chrome specific, provided via deprecated interface (PeerConnection constructor), and when this constraint is not set, Chrome collects or does not collect IPv6 candidates pretty much in random. Without setting this constraint, the same Chrome browser on the same network includes or does not include IPv6 candidates with no identifiable pattern. Because of this, we currently set googIPv6 constraint to false. Our only other alternative would be to examine the SDP and remove the IPv6 candidates and replace c= line with IPv4 address. In anticipation of IPv6 support being enabled by default, and to avoid SDP mucking, it would be better to define a constraint that can be used to suppress IPv6 candidate collection, which can be provided via current constraint interfaces.

What is the interop issue?  Are v6 candidates mistakenly attempted to be processed by Firefox and failing?

-d

---

From: Roman Shpount <[email-masked]>
Date: Tue, 7 Apr 2015 21:02:24 -0400

On Tue, Apr 7, 2015 at 8:30 PM, 🔓Dan Wing <[email-masked]> wrote:

> > It is possible to run into interop issues with end-points that support
> ICE and DTLS-SRTP but do not support IPv6, such as current versions of
> Firefox. Chrome currently offers googIPv6 constraint, which enables or
> disables IPv6 candidate collection. Unfortunately, this constraint is
> Chrome specific, provided via deprecated interface (PeerConnection
> constructor), and when this constraint is not set, Chrome collects or does
> not collect IPv6 candidates pretty much in random. Without setting this
> constraint, the same Chrome browser on the same network includes or does
> not include IPv6 candidates with no identifiable pattern. Because of this,
> we currently set googIPv6 constraint to false. Our only other alternative
> would be to examine the SDP and remove the IPv6 candidates and replace c=
> line with IPv4 address. In anticipation of IPv6 support being enabled by
> default, and to avoid SDP mucking, it would be better to define a
> constraint that can be used to suppress IPv6 candidate collection, which
> can be provided via current constraint interfaces.
>
>
setRemoteDescription fails when SDP has an IN IP6 address in the c= line. I
think parsing SDP iwth IPv6 addresses is fully supported by Firefox.
_____________
Roman Shpount

---

From: Adam Roach <[email-masked]>
Date: Tue, 07 Apr 2015 21:21:37 -0500

On 4/7/15 17:28, Roman Shpount wrote:
> Firefox. ... [I propose we] define a constraint that can be used to 
> suppress IPv6 candidate collection, which can be provided via current 
> constraint interfaces.

While full support of IPv6 in our ICE stack is going to require a 
significant amount of development work, I think it's a flaw if Firefox 
doesn't at least parse IPv6 candidates and recognize them as something 
it can't (currently) use. Just to make sure that we're not getting our 
wires crossed here: the JSEP stack was completely revamped in Firefox 37 
(which is the most recent released version). If you find that IPv6 
candidates are tripping Firefox 37 up, we should get a bug filed on that 
and fix it.

So, if that's the case, please report it at 
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=WebRTC%3A%20Networking 
-- or, if you'd prefer, send me an example of SDP and/or candidates that 
cause issues, and I'll file the bug myself.

But I don't think we need to make spec changes to work around 
implementation flaws. Any mishandling by Firefox is a temporary 
condition, and the spec will be around for a long time.

/a

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 8 Apr 2015 11:20:06 +0200

2015-04-08 0:28 GMT+02:00 Roman Shpount <[email-masked]>:
> it would be better to define a constraint that can be used to suppress
> IPv6 candidate collection

I'm against any approach or option that treats IPv6 as "optional" or
less important than IPv4. IMHO if Firefox fails (even) to parse IPv6
candidates, the vendor should fix it.

Said that, it is very *sad* that Firefox fails to parse an SDP due to
an IPv6 address in the c= line. Come on! this is about a grammar
defined more than 15 years ago!

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 9 Apr 2015 05:31:51 -0400

> defined more than 15 years ago!

We will retest Firefox 37 for IPv6, but this was really not the reason for
the constraint, but an illustration of the problem. This issue was brought
up as one of the examples of SDP mucking that is currently required to deal
with interop issues. Until IPv6 is implemented by default in both Chrome
and  Firefox, we will be in the state of transition. During this transition
all surrounding services would need to be updated to IPv6 and tested with
the browser implementations. Until this happens, IPv6 as a feature would
need to be disabled in the JavaScript client code. One way to do this is
via constraints, and Chrome already provides such a constraint. I assume
when Firefox will introduce IPv6 support, some sort of similar constraint
is going to be provided there as well. If such constraint will not be
provided, we will need to do SDP mucking, which everyone assumes is bad.

So, in the real world outside of standard committees and labs, each new
feature which is introduced needs to be controlled in such a way that it
can be deployed into production in gradual and managed manner. Since IPv6
is not a feature which was implemented from the start by the browsers, we
now need to manage the transition. This will take at least another year, or
at least this is how long it will take for Firefox 36 and older
installations to clear out. I understand that this is a short time frame in
comparison with the lifetime of the specification, but some solution for
managing the transition to IPv6 would be appreciated. I understand that in
this particular case a client side SDP filter for old Firefox versions
which removes IPv6 candidates and IPv6 address from the c= line can be
clunky but acceptable answer to this problem.

Regards,
_____________
Roman Shpount

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 10 Apr 2015 11:29:37 +0200

Den 09. april 2015 11:31, skrev Roman Shpount:
> On Wed, Apr 8, 2015 at 5:20 AM, Iñaki Baz Castillo <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     2015-04-08 0:28 GMT+02:00 Roman Shpount <[email-masked]
>     <mailto:[email-masked]>>:
> We will retest Firefox 37 for IPv6, but this was really not the reason
> for the constraint, but an illustration of the problem. This issue was
> brought up as one of the examples of SDP mucking that is currently
> required to deal with interop issues. Until IPv6 is implemented by
> default in both Chrome and  Firefox, we will be in the state of
> transition. During this transition all surrounding services would need
> to be updated to IPv6 and tested with the browser implementations. Until
> this happens, IPv6 as a feature would need to be disabled in the
> JavaScript client code.

<rant>
Just to make sure we're all on the same page here:

This is NOT what we're talking about.

We're talking about the c= line, which is meaningless semantic noise
added to SDP for backwards compatibility, and which all conformant
WebRTC implementations will ignore in favor of the ICE candidate lines.

The only purpuse the c= line has in the WebRTC context is to serve as
fodder for intercepting proxies that read the SDP and take action based
on the c= line because they don't understand ICE candidates.

The claim that has been made is that putting IPv6 addresses into the c=
line causes parsing of the SDP to fail in certain contexts.

If the only example of this issue is an old version of Firefox that will
go away at the speed at which Firefox replaces old versions - I say
"good riddance", and let's ignore the issue - it does not need solving.

If the issue exists for other ecosystem components (such as the
aforementioned proxies), this is a sad statement about the state of the
art in SDP parsing - but I could see an argument for changing the
generated default for this (semantically meaningless) value to be
something that makes fewer spec-violating parsers behave strangely.

This is NOT about introducing IPv6 - we've got address families in ICE
candidates for that, and nobody's reported a problem with those.

This is SOLELY about how far we bend over in order to not provoke broken
SDP parsers.

</rant>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 10 Apr 2015 13:54:03 +0200

2015-04-10 13:52 GMT+02:00 Iñaki Baz Castillo <[email-masked]>:
> Please don't add stuff to the WebRTC just to make some browsers' or
> WebRTC devices' old SDP stacks work. If a SDP stack in 2015 is not
> capable of parsing an IPv6 in the meaningless c= line that's vendor's
> fault and something the vendor must fix ASAP.

BTW: mangle the c= line (set there your favorite meaningless IPv4)
before providing setRemoteDescription() with the SDP and done.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 10 Apr 2015 13:52:26 +0200

> line causes parsing of the SDP to fail in certain contexts.

+1

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Justin Uberti <[email-masked]>
Date: Mon, 13 Apr 2015 19:01:44 -0700

FWIW, this was fixed in Chrome 42 to not put IPv6 addresses into the c=
line, when IPv4 addresses exist - because of these exact types of problems
encountered in the wild.

We think this is entirely consistent with RFC5245, which indicates the c=
line should contain the candidate most likely to work.

On Fri, Apr 10, 2015 at 4:54 AM, Iñaki Baz Castillo <[email-masked]> wrote:

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