Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)

Brian E Carpenter <brc@zurich.ibm.com> Mon, 20 September 2004 12:11 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 IAA25218; Mon, 20 Sep 2004 08:11:43 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9N7N-0004Yc-Us; Mon, 20 Sep 2004 08:18:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9MvB-0001oA-LP; Mon, 20 Sep 2004 08:05:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9Mu1-0001ba-Df; Mon, 20 Sep 2004 08:04:17 -0400
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 IAA24444; Mon, 20 Sep 2004 08:04:16 -0400 (EDT)
Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9N09-0004NA-MJ; Mon, 20 Sep 2004 08:10:39 -0400
Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i8KC3hfQ091302; Mon, 20 Sep 2004 12:03:43 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8KC3gO9083140; Mon, 20 Sep 2004 14:03:42 +0200
Received: from zurich.ibm.com (sig-9-145-241-76.de.ibm.com [9.145.241.76]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA80632; Mon, 20 Sep 2004 14:03:41 +0200
Message-ID: <414EC71C.6030109@zurich.ibm.com>
Date: Mon, 20 Sep 2004 14:03:40 +0200
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Pekka Savola <pekkas@netcore.fi>
References: <Pine.LNX.4.44.0409200834140.22679-100000@netcore.fi>
In-Reply-To: <Pine.LNX.4.44.0409200834140.22679-100000@netcore.fi>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: 7bit
Cc: iesg@ietf.org, ietf@ietf.org
Subject: Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
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: 769a46790fb42fbb0b0cc700c82f7081
Content-Transfer-Encoding: 7bit

I think the real point is that it's quite unrealistic at this
stage in the history of NAT to imagine that we can make the mess
(which was inevitable anyway) any better by codifying the
least-bad form of NAT behaviour. The NAT codes are shipped, burnt
into lots of devices, and the IETF can't do much about it.
So I think this would be wasted effort.

    Brian

Pekka Savola wrote:
> [[ Resending the comment to ietf@ietf.org as
> ietf-behave@list.sipfoundry.org illegitimately *) automatically
> rejects the posts by non-subscribers.
> 
> *) http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt
> ]]
> 
> On Fri, 17 Sep 2004, The IESG wrote:
> 
>>A new IETF working group has been proposed in the Transport Area.  The IESG has 
>>not made any determination as yet. The following description was submitted, 
>>and is provided for informational purposes only. Please send your comments to 
>>the IESG mailing list (iesg@ietf.org) by September 24.
> 
> 
> I do not think it's useful to spend too much energy in trying to 
> figure how NATs work (or do not work).
> 
> Further, even though the draft charter talks about IPv6 and eventual
> deployment, it seems to be ignoring the fact that if you use an IPv6
> transition mechanism which is specifically designed to traverse NATs
> (see e.g., draft-huitema-v6ops-teredo-xx [this should probably be on
> the 'reading list']), you don't have these problems.
> 
> And if you are able to use a transition mechanism which is not tied to
> the IP versions supported by your ISP own, the barrier for IPv6
> deployment should be significantly reduced.
> 
> Therefore the issue seems to boil down to whether the NAT traversal
> mechanism described in draft-huitema-v6ops-teredo-xx is sufficient to
> traverse the NATs, and whether the support for something like Teredo
> is expected to be sufficiently commonplace to depend on it.
>  

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf