Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=iso-8859-1
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <BLU152-W41B019AE5F8F004884506D93290@phx.gbl>
Date: Tue, 16 Aug 2011 14:02:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A891E7D-CDD3-42CE-9F93-9785756EEA4A@edvina.net>
References: <21A83EF5-206B-47CA-A055-C86E590EBEEF@edvina.net>,
 <4E48BFE5.9080504@alvestrand.no>
 <BLU152-W559E16682573CB4D4D269893260@phx.gbl>
 <3E59491C-459D-4D89-937D-5F38D4393D1C@edvina.net>
 <4E4A2B14.4090609@alvestrand.no>,
 <ECD4088D-58AF-40CE-B45C-3B9CE72629DF@edvina.net>
 <BLU152-W41B019AE5F8F004884506D93290@phx.gbl>
To: Bernard Aboba <bernard_aboba@hotmail.com>
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Dual stack RTCweb
Precedence: list

16 aug 2011 kl. 13:23 skrev Bernard Aboba:

> Harald said:=20
>=20
> > > I think the ICE procedure for connecting doesn't do any DNS =
lookups.
>=20
> [BA] Right.  The SRV RRs (and subsequent A/AAAA RRs) are used in =
signaling, not media and in any case, ICE is end-to-end. =20
>=20
> Olle said:
>=20
> > >> Now, if I have an IPv6 only client ICE won't help unless we force =
turn usage for IPv6 only clients so that they offer dual stack always =
(like the current recommendation for SIP).
> > > we can't force anything, but I do see IPv6-only clients as a =
powerful argument for offering dual-stack TURN servers.
>=20
> [BA] Even an IPv6-only client could need ICE if there is a NAT64 on =
their network.   And yes, relay candidates from a dual-stack TURN server =
could end up being
> selected.   Overall, the idea behind ICE is to be robust against =
network configurations, to the greatest degree possible.  So it's best =
not to say "we think IPv6 networks will generally be built in the =
following ways, so the following features of ICE are not needed".  =20
>=20
> > > I'm not 100% sure .... if client A is IPv6 only, and has a =
dual-stack TURN server, while client B is IPv4 only and does not have =
(or does not want to use) a TURN server .... will the connection =
complete in both directions?
>=20
> [BA] There first question is if A and B can communicate via SIP.   =
There could be a dual-stack SIP proxy somewhere, or maybe a NAT64 on the =
network, so that IPv6-A and IPv4-B could signal each other.=20
>=20
> If there is a way for media to flow between IPv6-A and IPv4-B, then =
ICE should find it.  This could be via NAT64 (server reflexive =
candidate) or via a dual stack TURN server (relay candidate). =20
>=20
> > This is one of the not covered cases in SIP. Most documents assume =
that everyone has IPv4 and very few assume single-stack Ipv6, something =
I think we need to start thinking more about.=20
>=20
> [BA] The SIP (and ICE) standards do cover this.  However, =
operationally we are still in the early stages, and so implementations =
may function well until they hit a deployment they didn't expect.  =20
I would not say that the SIP standards do cover dual stack and single =
stack use cases fully.  But that's an off-topic discussion here, I =
guess. We just need to make sure that we keep these issues in this =
discussion for media negotiation and possible signalling specs.

>=20
> > > It's easier to imagine that dual-stack TURN servers will be =
deployed usefully if only the service provider that wants to support the =
IPv6-only client will have to do anything.
>=20
> [BA] Some service providers may opt for NAT64 so an ICE implementation =
needs to handle this.=20

Well, when talking about apps in web browsers, we are talking about a =
large number of situations compared with where we have  "pure" sip =
deployments today (which is mostly managed networks).

/O=