Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix)
 with ESMTP id 6FE8711E819F for <rtcweb@ietfa.amsl.com>;
 Mon,  9 Sep 2013 10:01:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.226
X-Spam-Level: 
X-Spam-Status: No, score=-102.226 tagged_above=-999 required=5 tests=[AWL=0.372,
 BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com
 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sY9C9GjaPIE for
 <rtcweb@ietfa.amsl.com>; Mon,  9 Sep 2013 10:01:32 -0700 (PDT)
Received: from blu0-omc4-s15.blu0.hotmail.com (blu0-omc4-s15.blu0.hotmail.com
 [65.55.111.154]) by ietfa.amsl.com (Postfix) with ESMTP id B452B21F9D87 for
 <rtcweb@ietf.org>; Mon,  9 Sep 2013 10:01:30 -0700 (PDT)
Received: from BLU169-W24 ([65.55.111.136]) by blu0-omc4-s15.blu0.hotmail.com
 with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Sep 2013 10:01:29 -0700
X-TMN: [ZAouUi/1wypA/3Vbp8WGzApkrjYSeoJ4]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU169-W24E9BC13E0410CC38EBA2B933F0@phx.gbl>
Content-Type: multipart/alternative;
 boundary="_72251298-e3a3-42af-90dd-d4acfa7eeea6_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: cb.list6 <cb.list6@gmail.com>, "Hutton,
 Andrew" <andrew.hutton@siemens-enterprise.com>
Date: Mon, 9 Sep 2013 10:01:28 -0700
Importance: Normal
In-Reply-To: <CAD6AjGQXhGRBJxFtAF5oUa5mR_BPrPisPphdS9hdYVOP3Ez+Ng@mail.gmail.com>
References: <20130903094045.23789.92925.idtracker@ietfa.amsl.com>,
 <5225B1AF.7050906@alvestrand.no>,
 <9F33F40F6F2CD847824537F3C4E37DDF17BBC905@MCHP04MSX.global-ad.net>,
 <CAD6AjGQXhGRBJxFtAF5oUa5mR_BPrPisPphdS9hdYVOP3Ez+Ng@mail.gmail.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 09 Sep 2013 17:01:29.0222 (UTC)
 FILETIME=[3A145A60:01CEAD7E]
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] draft-ietf-rtcweb-transports-01 TURN/IPV6 RFC 6156.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list
 <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>,
 <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>,
 <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Sep 2013 17:01:51 -0000

--_72251298-e3a3-42af-90dd-d4acfa7eeea6_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> I would specifically state that much of the challenges with NATs are
> resolved by preferring IPv6.
 [BA] That isn't what we've seen in practice=2C since IPv6 addresses (parti=
cularly tunnel addresses) may not be routable. So in practice=2C things see=
m to work better if IPv4 addresses are preferred and in fact=2C government =
profiles such as DISA UCR 2008 require the ability to configure an IPv4 pre=
ference. =20
> I would also cover the use case of using TURN to bridge IPv6-only
> clients to communicate with IPv4 clients.
[BA] Yes=2C this is an important use case (and one that some ICE implementa=
tions don't support very well). =20
> It would also be wise to reference RFC6540 to underscore that IPv6 use
> is a BCP of the IETF.
 		 	   		  =

--_72251298-e3a3-42af-90dd-d4acfa7eeea6_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 12pt=3B
font-family:Calibri
}
--></style></head>
<body class=3D'hmmessage'><div dir=3D'ltr'><div>&gt=3B I would specifically=
 state that much of the challenges with NATs are<br>&gt=3B resolved by pref=
erring IPv6.<br>&nbsp=3B</div><div>[BA] That isn't what we've seen in pract=
ice=2C since IPv6 addresses (particularly tunnel addresses) may not be rout=
able.&nbsp=3B</div><div>So in practice=2C things seem to work better if IPv=
4 addresses are preferred and in fact=2C government profiles such as DISA U=
CR 2008 require the ability to configure an IPv4 preference. &nbsp=3B</div>=
<div><br>&gt=3B I would also cover the use case of using TURN to bridge IPv=
6-only<br>&gt=3B clients to communicate with IPv4 clients.</div><div><br></=
div><div>[BA] Yes=2C this is an important use case (and one that some ICE i=
mplementations don't support very well). &nbsp=3B</div><div><br>&gt=3B It w=
ould also be wise to reference RFC6540 to underscore that IPv6 use<br>&gt=
=3B is a BCP of the IETF.<br></div> 		 	   		  </div></body>
</html>=

--_72251298-e3a3-42af-90dd-d4acfa7eeea6_--
