Re: FW: Why?
Jonathan Rosenberg <jdrosen@cisco.com> Mon, 14 March 2005 15:42 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14223; Mon, 14 Mar 2005 10:42:29 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DArlq-0007YF-9i; Mon, 14 Mar 2005 10:46:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DArbV-0005nK-Bf; Mon, 14 Mar 2005 10:35:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DArbT-0005nE-SF for ietf@megatron.ietf.org; Mon, 14 Mar 2005 10:35:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13659 for <ietf@ietf.org>; Mon, 14 Mar 2005 10:35:33 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DArf7-0007Bf-0I for ietf@ietf.org; Mon, 14 Mar 2005 10:39:22 -0500
Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 14 Mar 2005 07:35:37 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j2EFYrYO025414; Mon, 14 Mar 2005 07:34:54 -0800 (PST)
Received: from [192.168.1.100] (che-vpn-cluster-1-242.cisco.com [10.86.240.242]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIN85865; Mon, 14 Mar 2005 07:34:52 -0800 (PST)
Message-ID: <4235AF1B.1080702@cisco.com>
Date: Mon, 14 Mar 2005 10:34:51 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tony Hain <alh-ietf@tndh.net>
References: <200503112324.SAA18522@ietf.org>
In-Reply-To: <200503112324.SAA18522@ietf.org>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: FW: Why?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Content-Transfer-Encoding: 7bit
inline. Tony Hain wrote: > Joel M. Halpern wrote: > >>This discussion seems to take as a premise the view that if we define >>applications only on IPv6, even though they could be defined on IPv4, that >>this will give people a reason to use IPv6. >>It also seems to take as a premise that if we don't define ways to work >>around NATs, people won't use the applications with NATs. > > > I suffer from no such disillusions as those are not the premise for the > initial note, though without having the background in the original note it > is easy to see why someone might come to that conclusion. > > My assumption is that the market will not ignore the opportunity to develop > NAT traversal technologies. That does not equate to a need for the IETF to > waste valuable resources standardizing hacks that attempt to mask previous > hacks. In particular the IAB needs to be looking forward and helping the > application community understand that there are approaches today that allow > them to ignore the nonsense that has grown in the network by using IPv6 > tunneling as a NAT traversal tool. This approach completely avoids the need > for complex and error prone ALGs. I agree that ALGs are not the answer, and I believe the reasons for that are treated in: http://www.ietf.org/internet-drafts/draft-iab-nat-traversal-considerations-00.txt As I mentioned during the plenary, the document above makes a case that the right answer in many situations are vpn-ish technologies that include v6 tunnels. However, different applications have different needs, and there are real differences between the various vpn-ish solutions (TURN, STUN, teredo, etc.) that are driving their development and adoption. For VoIP, where the nat traversal issue has been especially painful, the increase in voice latency, packet loss, and substantial cost increase of relaying traffic through the tunnel servers, has driven people to solutions like STUN. Thus, I cannot agree that there only needs to be a single solution here. That said, I agree that the IAB nat traversal consideration document lacks adequate consideration of how evolution plays into this, and I'll endeavor to improve the document on that front. Another concern I have is that, in an IPv6-only world, even if you eliminate NAT, there will still be firewalls, and those firewalls will frequently have the property that they block traffic coming from the outside to a particular IP/port on the inside unless an outbound packet has been generated from the inside from that IP/port. This means that IP addresses are not globally reachable. You'd still need most of the same solutions we have on the table today to deal with this problem. Indeed, in the VoIP space, I believe you'd need pretty much everything, excepting you'd be able to remove a single attribute from a few of the protocols (STUN and TURN in particular), which tell the endpoint its address on the other side of the NAT. The endpoint knows its address, but all of the protocol machinery is still needed to rendezvous with the other participant in the call. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Re: FW: Why? JFC (Jefsey) Morfin
- FW: Why? Tony Hain
- Re: FW: Why? Erik Nordmark
- Re: FW: Why? shogunx
- Re: FW: Why? Joel M. Halpern
- Re:Why? JORDI PALET MARTINEZ
- Re: FW: Why? Noel Chiappa
- Re:Why? Edward Lewis
- Re: FW: Why? JFC (Jefsey) Morfin
- Re:Why? JORDI PALET MARTINEZ
- Re:Why? JORDI PALET MARTINEZ
- Re: FW: Why? Tim Chown
- RE: FW: Why? Michel Py
- RE: FW: Why? Ralph Droms
- Re: FW: Why? Tim Chown
- Re: FW: Why? shogunx
- RE: FW: Why? Michel Py
- Re: FW: Why? Steven M. Bellovin
- Re: FW: Why? Kevin Loch
- Metcalfe's Law challenged Steve Crocker
- Re: FW: Why? JFC (Jefsey) Morfin
- RE: FW: Why? Tony Hain
- Re: Why? Keith Moore
- Re: Why? Keith Moore
- Re: Why? Noel Chiappa
- Re: Why? Keith Moore
- RE: Why? Michel Py
- Re: Why? Kevin Loch
- Re: Why? Bill Manning
- Re: Why? Noel Chiappa
- Re: Why? shogunx
- RE: Why? Noel Chiappa
- RE: Why? Michel Py
- Re: Why? Keith Moore
- RE: Why? Michel Py
- Re: Why? Keith Moore
- Re: Why? shogunx
- Re: Why? Bill Manning
- RE: Why? Michel Py
- Re: Why? Noel Chiappa
- Re: Why? JFC (Jefsey) Morfin
- Re: Why? Keith Moore
- Re: Why? Keith Moore
- Re: Why? Terry Gray
- RE: Why? Michel Py
- Re: Why? Brian E Carpenter
- Re: FW: Why? Tom Petch
- Re:Why? JORDI PALET MARTINEZ
- Re: FW: Why? Jonathan Rosenberg
- Re:Why? JORDI PALET MARTINEZ
- Re: Why? Noel Chiappa
- RE: FW: Why? Tony Hain
- RE: FW: Why? Pyda Srisuresh
- RE: Why? Michel Py
- RE: FW: Why? Tony Hain
- Re: FW: Why? Juergen Schoenwaelder
- Re: Why? Keith Moore
- Re: Why? David R Oran
- Re: Why? Theodore Ts'o
- Re: Why? Keith Moore
- Re: FW: Why? Brian E Carpenter
- Re: Why? Keith Moore
- Re:Why? JORDI PALET MARTINEZ
- Re: FW: Why? Melinda Shore
- Re: Why? Noel Chiappa
- RE: FW: Why? Noel Chiappa
- Re: Why? Keith Moore
- Re: Why? Brian E Carpenter
- Re: Why? Melinda Shore
- Re: Why? Keith Moore
- Re: FW: Why? Joe Touch
- Re: FW: Why? Joe Touch